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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Human Factors (HE). 
Intended readers of the present document are: 

• standards developers; 

• terminal manufacturers; 

• assistive device manufacturers; 

• network operators; 

• service providers; 

• software developers; 

• regulatory authorities; 

• policy makers. 



Introduction 

An eEurope community that promotes fair and comprehensive access to advanced information and communication 
services for all citizens must ensure that those citizens whose disabilities are such that they cannot use devices 
"designed-for-all" are not excluded from the common access policies. 

In principle, all European citizens expect to have access to information through technology mediated services and 
devices. In the context of this report, this implies that all citizens can choose to have access through mobile platforms, 
and to choose the complexity of the devices and the range of services that meet their needs, at reasonable and equitable 

costs. 

Some users with disabilities, however, are unable to use conventional devices and services, even those designed 
according to the "design-for-all" principles, as their disabilities are too severe or their requirements conflict with those 
of people with a different disability. In this case, these users should be able to choose the mobile devices that they need 
to use, and to easily and cheaply enhance those devices and services with an adaptation appropriate to their needs. 
Examples could include a speaking output adaptation for blind people or icon representation of functions for people 
with reduced reading skills. 
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In order for this objective to be realised, mobile devices and services should be implemented with a standardized set of 
interfaces that can be the channel through which these adaptations become integrated with the rest of the system. 
Without this standardized interface, each adaptation will require significant technical expertise and effort, and will 
consequently be expensive and practically unrealistic. People with disabilities will be confined to using a small subset 
of the available devices and services, and will not be able to join other citizens in selecting devices and services 
according to personal preferences (e.g. style, design, functionality), but instead will have to persist with using specific 
devices long after they have ceased to be supported by manufacturers and operators, simply because it is impossible to 
replace them. 

A standardized set of interfaces will, therefore, encourage growth in the market for mobile devices and services by 
enabling the large numbers of disabled and elderly people who are currently excluded to participate, and the strength of 
the European rehabilitation technology market, particularly the small and medium enterprises that currently dominate 
this sector. 

As one candidate technology that is present in all mobile devices is AT commands, the work to promote increased 
accessibility and adaptability of the mobile devices is expected to include the upgrading of existing standards where the 
necessary AT commands [2] and [3] do not exist (as recommended in "Requirements for assistive technology devices in 
ICT" [7]). 

Requirements on this set of interface standards have been collected in a process which has involved manufacturers of 
assistive devices and groups representing the user with different special needs. The draft versions have been presented 
to appropriate standards fora (e.g. 3GPP) and interested mainstream mobile device manufacturers. 

The present document also provides a basis for national regulatory authorities to implement the Framework Directive 
(2002/21/EC) [28], enable member states to take specific measures for disabled end-users in order to ensure access to 
publicly available telephone services and emergency services in accordance with the Universal Service Directive 
(2002/22/EC) [29] and facilitate the implementation of the PubUc Procurement Directive (2004/1 8/EC) [36]. 
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Scope 



The present document sets out the requirements for new AT command protocols that can be used to enable assistive 
devices to interwork satisfactorily with mobile terminals over a range of suitable interfaces. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the purposes 
of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EG 202 1 16: "Human Factors (HF); Guidelines for ICT products and services; "Design for 

All"". 

[2] ETSI TS 127 007: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); AT command set for User Equipment (UE) 
(3GPP TS 27.007 Release 7)". 

[3] ETSI TS 127 005: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Use of Data Terminal Equipment - Data Circuit 
terminating Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell 
Broadcast Service (CBS) (3GPP TS 27.005 Release 7)". 

[4] ISO 639-1 (2002): "Codes for the representation of names of languages — Part 1: Alpha-2 code". 

[5] ISO 639-2 (1998): "Codes for the representation of names of languages - Part 2: Alpha-3 code". 

[6] "vCalendar The Electronic Calendaring and Scheduling Exchange Format Version 1.0". 

2.2 Informative references 

[7] ETSI TR 102 068: "Human Factors (HF); Requirements for assistive technology devices in ICT". 
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[8] ETSI EG 202 421: "Human Factors (HE); Multicultural and language aspects of multimedia 

communications " . 

[9] ETSI EG 202 325: "Human Factors (HF);User Profile Management". 

[10] ETSI TS 101 369: "Digital cellular telecommunications system (Phase 2+); Terminal Equipment 

to Mobile Station (TE-MS) multiplexer protocol (3GPP TS 07.10 version 7.2.0 Release 1998)". 

[11] ETSI TS 122 226: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Global text telephony (GTT); Stage 1: Service description 
(3GPP TS 22.226 version 6.0.0 Release 6)". 

[12] ETSI TS 126 1 14: "Universal Mobile Telecommunications System (UMTS); IP Multimedia 

Subsystem (IMS); Multimedia telephony; Media handling and interaction (3GPP TS 26.1 14)". 

[13] ETSI TS 101 267: "Digital cellular telecommunications system (Phase 2+); Specification of the 

SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM-ME) 
interface (3GPP TS 11.14)". 

[14] ETSI TS 131 111: "Digital cellular telecommunications system (Phase 2+);Universal Mobile 

Telecommunications System (UMTS);Universal Subscriber Identity Module (USIM) Application 
Toolkit (USAT) (3GPP TS 31.111 version 7.5.0 Release 7)". 

[15] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT) (Release 7)". 

[16] "IrDA Object Exchange (OBEX) Protocol". 

NOTE: Available at http://www.irda.org/. 

[17] "Specification of the Bluetooth System; Volume 1; Core, Revision 1.1". 

NOTE: Available at http://www.bluetooth.org . 

[18] "Specification of the Bluetooth System; Volume 2; Profiles, Revision 1.1". 

NOTE: Available at http://www.bluetooth.org . 

[19] ITU-T Recommendation T.140 (1998): "Text conversation protocol for multimedia application, 

with amendment 1, (2000)". 

[20] ITU-T Recommendation V.250: "Serial asynchronous automatic dialling and control". 

[21] ITU-T Recommendation V.251: "Serial asynchronous automatic dialling and control". 

[22] ITU-T FSTP-TACL: "Telecommunications AccessibiHty Checklist". 

[23] ITU-T Recommendation F.790 Telecommunications Accessibility Guidelines for Older Persons 

and Persons with Disabilities. 

[24] ISO 9999: "Technical aids for disabled persons; Classification". 

[25] CENASSS (2000): "ICTSB Project Team: Design for All". 

NOTE: Available at http://www.ict.etsi.fr/Activities/Documents/execsum.pdf . 

[26] CEN/CENELEC Guide 6: "Guidelines for standards developers to address the needs of older 

persons and persons with disabilities". 

[27] "Device Management specifications. Open Mobile Alliance (OMA), Device Management 

Working Group". 

[28] Directive 2002/2 1/EC of the European Parliament and of the Council of 7 March 2002 on a 

common regulatory framework for electronic communications networks and services (Framework 
Directive). 

NOTE: Available at http://europa.eu.int/eur-lex/pri/en/oi/dat/2002/l 108/1 10820020424en00330050.pdf . 
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[29] Directive 2002/22/EC of the European Parliament and of the Council of 7 March 2002 on 

universal service and users' rights relating to electronic communications networks and services 
(Universal Service Directive). 

NOTE: Available at http://europa.eu.int/eur-lex/pri/en/oi/dat/2002/l 108/1 10820020424en005 10077.pdf . 

[30] COCOM 04-08: "Report from the inclusive communications (INCOM) subgroup". 

[31] Roadmap towards Accessible Communication. Draft report from TCAM eWGD on accessible ICT 

2006-10-19, Sub-group 1: Accessible Communication. 

NOTE: Available at http://circa.europa.eu/Public/irc/enterprise/tcam/librarv?l=/pubhc documents/team 21/1- 

tcam-ewgdl -draft/ EN 1.0 &a=i. 

[32] Symbian OS'"^ v9. 1 Product description, Sander Siezen, SymbianTM, February 2005. 

[33] Radio Interface Layer (RIL) White Paper, Microsoft Corporation, June 2004. 

[34] Report on Access to Mobile Telephony for Handicapped Persons. CCR, French 

Telecommunications Regulator Working Group on Access to Mobile Telephony for handicapped 
Persons (October 2003). 

NOTE: Available at http://www.art-telecom.fr/uploads/tx gspublication/rapport -balin-eng.doc . 

[35] BREW^'^, Binary Runtime Environment for Wireless, Qualcomm. 

NOTE: Available at http://brew.qualcomm.com. 

[36] Directive 2004/1 8/EC of the Parliament and of the Council of 3 1 March 2004 on the coordination 

of procedures for the award of public works contracts, public supply contracts and public service 
contracts. 

[37] ISO/lEC FCD 24752-1: "Information technology — User interfaces — Universal remote console — 

Part 1: Framework". 

[38] ISO/lEC FCD 24752-2: "Information technology — User interfaces — Universal remote console — 

Part 2: User Interface Socket Description". 

[39] ISO/lEC FCD 24752-3: "Information technology — User interfaces — Universal remote console — 

Part 3: Presentation Template". 

[40] ISO/lEC FCD 24752-4: "Information technology — User interfaces — Universal remote console — 

Part 4: Target Description". 

[41] ISO/lEC FCD 24752-5: "Information technology — User interfaces — Universal remote console — 

Part 5: Resource Description". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

assistive technology device: device used by a disabled person to prevent, compensate, relieve or neutralize any 
resultant handicap and which has the ability to interface to an ICT device 

NOTE: The term assistive device is used for mobile assistive device or assistive technology device. 

AT: two character abbreviation used to start a command line sent from terminal equipment to a terminal adaptor 

Bluetooth®: wireless technology enabling secure transmissions of both voice and data 

built-in modem: functionally separate internal modem which is mechanically combined with a terminal 
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design for all: design of products to be usable by all people, to the greatest extent possible, without the need for 
specialized adaptation 

ICT device: device for processing information and/or supporting communication which has an interface to 
communicate with a user 

IrDA: industry consortium set up to define a set of short range infrared communications standards 

mobile device: used for mobile ICT device, e.g. mobile phone, PDA 

OBject Exchange Protocol (OBEX): protocol for the exchange of data objects between devices 

SIM Application Toolkit: set of applications and related procedures which may be used during a GSM session 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACM Accumulated Call Meter 

ASCII American Standard Code for Information Interchange 

AT ATtention 

ATCI AT Communication Interface 

CAN Car Area Networks 

CAT Card Application Toolkit 

CBS Cell Broadcast Service 

CSY Comms Server protocol 

CUG Closed User Group 

EAP Extensible Authentication Protocol 

eMLPP enhanced Multi-Level Precedence and Pre-emption service 

FTP File Transfer Profile 

GSM Global System for Mobile communication 

HFP Hands-Free Profile 

HID Human Interface Device (profile) 

IMS IP Multimedia Subsystem 

INCOM INclusive COMmunications subgroup 

IR InfraRed 

IrDA Infrared Data Association 

IRLAN Infrared Local Area Network 

IrOBEX Infrared OBject EXchange 

ISM Industrial, Scientific and Medical 

ISO International Organization for Standardization 

ME Mobile Equipment 

MMS Multimedia Messaging Service 

NIF Network InterFace 

OBEX OBject EXchange 

OMA Open Mobile Alliance 

PBAP Phone Book Access Profile 

PCMCIA Personal Computer Memory Card Industry Association 

POS Point-Of-Sales 

RIL Radio Interface Layer 

RNIB Royal National Institute of Blind people 

SAT SIM Application Toolkit 

SIM Subscriber Identity Module 

SMS Short Message Service 

SPP Serial Port Profile 

SyncML Synchronization Markup Language 

TSY Telephony sub SYstem 

TTS Text-To-Speech 

UICC Universal Integrated Circuit Card 

URC Universal Remote Console 

USAT USIM Application Toolkit 

USB Universal Serial Bus 
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USIM 
VAS 
VBS 
VGCS 



Universal Subscriber Identity Module 
Value Added Services 
Voice Broadcast Service 
Voice Group Call Service 



Background and issues 



4.1 



Introduction 



This clause introduces the problem space and the current status of assistive technology and mobile device technology. 

Abilities and disabilities are explained in EG 202 116 [1]. The guideline document describes the characteristics of a 
wide range of users with disabilities and provides details of their impairments and the resulting disabilities related to 
ICT products and services. In the context of the present document, the following broad classes of abilities are 
highlighted, and when impaired, they affect the use of mobile technologies: 

• sensory abilities such as seeing, hearing, touch, taste, smell and balance; 

• physical abilities such as speech, dexterity, manipulation, mobility, strength and endurance; 

• cognitive abilities such as intellect and memory; 

• language abilities such as speaking, reading, literacy and comprehension. 

These abilities are also described in the document CEN/CENELEC Guide 6 [26] and in the ITU-T FSTP 
Telecommunications Accessibility Checklist [22], which provide guidelines for standards developers to address the 
needs of older people and people with disabilities. The range of disabilities put requirements on services and devices. 
Some of those requirements can be met by following the "Design for All" guidelines (EG 202 1 16 [1]). However, some 
users, often with multiple disabilities need additional assistance in the form of adaptations to conventional devices. It is 
therefore important to collect requirements in this area and the present document builds therefore on the results 
provided in the technical report on "Requirements for assistive technology devices in ICT" (TR 102 068 [7]). The 
ITU-T Recommendation F.790 [23] provides Telecommunications accessibility guidelines for older persons and 
persons with disabilities. Therefore, the present document provides requirements based on requirements listed in 
existing documents, input from stakeholders (see clause 6) and a gap analysis where existing AT commands have been 
reviewed (see clause 7). Annex A provides a requirement summary and annex E provides suggested syntax of some 
required new AT commands. Annex G presents suggested solutions related to the development of mobile devices in 
order to facilitate the development and use of assistive devices. Annex H presents specific requirements and the need 
for AT commands to support those requirements. 

4.2 Assistive technology interfacing 

4.2.1 When assistive devices are needed 

Some users with disabilities cannot use mobile technologies, even those designed using "design-for-all" principles [1] 
and [25]. In some cases, the requirements for different disabilities conflict with the requirements for other disabilities. 
Therefore, what is required for those users is a standard solution for adaptation. 

4.2.2 Classification of assistive devices 

Current assistive technology is classified in the international standard ISO 9999 [24]. Although it covers a vast number 
of devices ranging from abacuses and abdominal hernia aids to zip pullers and zippers, only a few of the devices listed 
in that standard have the potential to be interconnected to ICT services and devices. TR 102 068 [7] has therefore listed 
those assistive devices which can be interconnected to ICT systems, see table 1, together with their codes according to 
the ISO 9999 [24] classification system. 
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Table 1 : Relevant assistive devices in ISO 9999 [24], listed in TR 102 068 [7] 



Classification code 


Description 


1 2 39 06 


Electronic orientation aids 


12 39 09 


Acoustic navigation aids (sound beacons) 


21 06 03 


Image enlarging video system 


21 06 06 


Character reading machine 


21 09 03 


Input units (e.g. speech recognition) 


21 09 06 


Keyboard and control systems 


21 09 09 


Printers and plotters (e.g. Braille) 


21 09 12 


Displays 


21 09 15 


Devices for synthetic speech 


21 09 27 


Software for input and output modification 


21 15 09 


Dedicated word processors 


21 15 15 


Electric Braille writers 


21 24 


Aids for drawing and handwriting 


21 33 09 


Decoders for videotext 


21 33 12 


CCTV 


2136 06 


IVIobile telephones and car telephones 


21 36 09 


Text telephones 


21 36 10 


Visual telephones and videophones 


21 42 09 


Portable dialogue units 


21 42 12 


Voice generators 


21 42 15 


Voice amplifiers 


21 45 


Hearing aids 


21 45 15 


Tactile hearing aids 


21 48 03 


Door signals 


21 51 03 


Personal emergency alarm systems 


21 51 06 


Attack alarms for epileptics 


21 51 09 


Fire alarms 


24 09 


Operating controls and devices 


24 12 


Environmental control systems 



The list in table 1, from TR 102 068 [7], cannot be considered to be exhaustive but it provides some indication of the 
extensive range of possibilities for interconnecting assistive devices to ICT systems. An important category of assistive 
devices not listed in table 1 is "Software for Total Conversation" with classification code 21 36 90. As can be seen, in 
some cases the assistive device may be a mainstream device normally used for another purpose (e.g. a mobile phone 
used as a text phone). 



4.3 Scope of AT commands 



Originally developed for computer modems in 1977 by Hayes Microcomputer Products, AT commands have matured 
from being a modem control technology to be a comprehensive and pervasive middleware platform for mobile devices. 
AT commands provide control of calls, the SIM card, phone information, phone settings, packet domain, network 
services, and mobile termination in the mobile device TS 127 007 [2]. Currently, a set of AT commands has been 
standardized, but only a few AT commands of these are mandatory. However, many mobile devices do not have this 
standardized set fully implemented. In addition, a number of manufacturers of mobile devices have extended the AT 
command set to cover additional functions in the phone such as file storage, camera, etc. The manufacturers have 
gathered these extensions to the AT command set as company specific documents, some of which are publicly 
available, some of which are not. It is likely, though difficult to verify, that not all mobile devices from the same 
manufacturer will have the full set of standardized and proprietary AT commands implemented within it. Further details 
on AT commands are provided in annex F. 
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4.4 Limitations 



Currently, there is only a very limited range of assistive solutions available for mobile devices, as the adaptations used 
by people with disabilities are only compatible with a few models of mobile devices. Assistive device and adaptation 
developers state that this is due to selective implementations of the standard AT command set, since not all of the 
commands specified in TS 127 007 [2] are mandatory. Therefore, the assistive devices need to be tuned to match each 
specific mobile device model. The consequences are higher development costs of assistive devices and also that the 
assistive device users only have limited choices when acquiring a new mobile device (see scenario in clause 5.2). Also, 
these users might be limited to doing very basic tasks such as making and receiving calls and use the SMS service. 

Realistically, it is understood that new mobile device technologies are developing rapidly. Therefore the standardized 
AT command set will need to be periodically updated and revised. All mobile devices should by definition carry the 
standardized AT command set in a firmware library and use the subset of AT commands necessary to make the 
particular phones functions available to users. In this way, assistive device manufacturers (or indeed any company 
interested in making generic accessories for mobile devices) will have the confidence to know that an adaptation will 
work with all devices that have the function being adapted. 



Usage Scenarios 



5.1 Introduction 

This clause contains scenarios which illustrate the way that mobile devices can be used together with assistive devices. 
The scenarios highlight some interesting concepts and are not intended to illustrate all alternative solutions. 

5.2 Buying a new mobile phone 

Issues addressed 

The scenario illustrates: 

• buying a new mobile phone, for replacing the old one; 

• standardized AT commands vs. proprietary AT commands. 

Current situation 

Anna is visually impaired. When Anna's mobile device is broken for the second time, she decides not to get it repaired. 
Instead she decides to buy a new one. As she has spent a lot of money on her vacation in Spain, she does not want to by 
a new assistive device - only a new mobile phone. She collects information about various models of mobile phones, 
from various manufacturers, and it becomes clear which phone she desires to buy. The problem is that her preferred 
option is not compatible with her assistive device as the manufacturer has implemented their own proprietary 
commands for some of the functionalities that she is interested in. 

Anna's options are: 

• either to collect information about mobile devices that are compatible with her assistive device, and chose one 
of those. That is not an option she likes as her choices become very limited; or 

• to buy a new assistive device that is compatible with the mobile phone of her choice. Unfortunately this is not 
really an option as she can not afford right now to buy a new assistive device. 

Future scenario 

Anna has the same possibilities when choosing a new mobile phone as everyone else, since her assistive device is 
compatible with all suitable mobile phones on the market. The reason that her assistive device is compatible with all 
mobile phones is that they have implemented the whole set of standardized AT commands (including the harmonized 
set of AT commands covering the extended functionalities of modern mobile devices). 
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5.3 Using a voice output communication aid over the phone 

Issues addressed 

The scenario illustrates: 



• 



Using a voice output communication aid (Voice Output Communication Aid) to talk through a mobile phone 
(see requirement on a new AT command for menus in clause H.19. 

• Controlling a mobile phone through the environmental control interface within a voice output communication 
aid. 

Current situation 

John is unable to speak and has reduced dexterity. John would like to be able to use the digital speech generated by his 
voice output communication aid as input into a mobile phone, but to couple it directly rather than use a speaker on his 
voice output communication aid and the microphone on the mobile. He would also like to use the switch based interface 
that he uses with his voice output communication aid and its inbuilt environmental control functions to control the 
mobile, just as he currently does to control the TV, music player, etc. 

John's options are to: 

• Ask someone with good dexterity to make a call with the phone, set the phone to hands free or to connect the 
Bluetooth® headset, mount the phone near and then use the voice output communication aid to generate 
speech that is picked up by the microphone of the phone. 

• Insert a phone in the form of a card (e.g. PCMCIA) into a computer, and attempt to control the card via the 
environmental control interface on the voice output communication aid. Speech will also be handled via the 
speaker on the voice output communication aid and the microphone on the computer. This is likely to be less 
private than a closely coupled voice output communication aid and phone. 

Future scenario 

The following alternatives could be considered: 

• Mount a phone in the form of a (PCMCIA) card into a voice output communication aid, and use the 
environmental control functionality on the voice output communication aid to control the phone. Feed the 
digital speech signal directly into the digital audio input of the phone, providing as much privacy as the user 
desires. 

• Connect a phone via a USB cable to the output of the voice output communication aid, and use the 
environmental control functionality on the voice output communication aid to control the phone. Feed the 
digital speech signal directly into the digital audio input of the phone, providing as much privacy as the user 
desires. 

5.4 Usable menus 

Issues addressed 

The scenario illustrates: 

• talking menus; 

• menus on an external larger screen (see requirement on a new AT command for menus in clause H. 10); 

• personalization of menus; 

• preferences in user profiles; 

• privacy issues. 
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Current situation 



1) Alex is dyslexic and visually impaired. He finds the screen of his mobile phone very small and it is almost 

impossible to operate his mobile phone as he cannot navigate the menus. Currently, his mobile phone does not 
allow him to choose his favourite background colour which is specifically useful as he is dyslexic. Neither can 
he have large font sizes. 

Future scenario 

Alex's mobile phone is implemented with the new standardized AT commands for menus which allow him to choose 
among the two following alternatives: 

• He has his preferences stored in a user profile. Alex finds these preferences very convenient when using 
various PCs, as whenever he uses a PC it will automatically adjust to his preferences. As he is dyslexic, he 
uses a green background colour which he finds much more suitable for his specific condition than other 
background colours. In addition, as he is visually impaired, he has chosen larger font sizes. Both the green 
background colour and large fonts are preferences stored in his user profile. 

When he bought a new mobile phone which could provide menus to his assistive devices with an external, 
larger screen, he finds it great to be able to let the larger screen display the menus according to his preferences, 
with a green background and larger fonts. 

• He uses the spoken menus functionality. However, as Alex feels that he does not want other people to listen 
when navigating for example in the mobile phone book, he is using a headset. He finds that he can easily 
control his mobile phone as it is so convenient navigating with spoken menus. 

5.5 Using a camera on the phone 

Issues addressed 

The scenario illustrates: 

• The use of a camera on a phone by a person with reduced manual dexterity in a wheelchair. 

• Controlling a mobile phone through a wheelchair mounted environmental control interface (see requirement 
on a new AT command for camera in clause H.6). 

Current situation 

Jackie uses a motorized wheelchair, has impaired speech and has reduced dexterity. She would like to be able to use the 
camera built into her mobile to take spontaneous photos of things she encounters day by day, so that she can use these 
photos as a way of communicating about her life. 

Jackie's options are to: 

• Ask someone with good dexterity to take a photo for her. 

• Buy a camera, have it adapted so that it can be used via her environmental control device, and find a strategy 
for moving photos from the camera to her computer. This will mean an additional device being mounted on 
her wheelchair in addition to the phone and the environmental control unit. Jackie is, however, more interested 
in capturing the spontaneity of the moment than the ultimate quality of the photo. 

Future scenario 

The following alternatives could be considered: 

• Mount a phone on her wheelchair, and use either Bluetooth® or a USB cable to connect the camera to the 
environmental control unit in order to control the camera. 

• Provide voice commands (a selection of utterances in this case), for the phone functions, delivered through the 
Bluetooth® headset coupled to the phone. 
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5.6 Video telephony 

Issues addressed 

The scenario illustrates: 

• The use of video conferencing by a deaf person with visual impairment (see requirement on a new AT 
command for video telephony in clause H.18). 

Current situation 

John is deaf and has a visual impairment. He would like to do video conferencing in sign language with his friends. 
John's options are to: 

• Ask someone to make the call for him and communicate in sign language with that person. 

• Connect the phone to a computer and use third party video conferencing software to get a larger video image. 
Future scenario 

The following alternatives could be considered: 

• Show the received video in full screen and rotate the video to make the best use of the screen. 

• Connect the phone to a large external screen and show the received video on it. 



Stakeholders 



6.1 Overview 

This clause presents the identified stakeholder categories and explains an overview of their needs and requirements. The 
primary stakeholder category are the end-users, often represented by user representatives. It is important to meet the 
requirements of the end-users, in order to provide useful assistive devices. The secondary stakeholder category are the 
assistive device developers, who are directly dependent on the availability of implemented standardized AT commands. 
The third stakeholder category are the manufacturers of mobile devices, who are responsible for implementing the 
standardized AT commands in order to let the assistive device developers benefit from the advantages of standardized 
AT commands. Standardization bodies, regulatory authorities and Emergency services are also identified as being 
stakeholders. The questionnaires used for collecting stakeholder input can be found in annex B. 

6.2 Users 

The users addressed in the present document include those people whose disabilities, often multiple disabilities, are 
such that they cannot use devices designed for all. It is crucial for them that affordable, effective and usable assistive 
devices are available. The assistive devices shall be able to easily connect to and interact with a multitude of mobile 
devices, from various vendors. 

Their user needs depend on their specific disabilities and which assistive device(s) they wish to use. However, a major 
requirement is that: 

• people with disabilities should be able to use the same set of functionality as non-disabled people; and 

• disabled individuals should be able to use the same set of functionality as they used before they became 
disabled. There is no functionality in mobile devices that can be considered as useful only to able bodied 
people. The consequence of this is that all functionality in mobile devices shall be accessible by standardized 
AT commands. 

For users who already have an assistive device, the goal is that they should be able to buy new mobile devices, without 
having to worry about needing to buy a new assistive device that will be compatible with the new mobile device. 
However, in practice there will be a limit when mobile devices may no longer be backward compatible. 
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This goal is only expected to be partially fulfilled because all mobile devices cannot be expected to implement all new 
AT Commands until they are standardized. 

It would therefore be useful if users could be informed about which functionalities and features are accessible through 
the standardized AT command set that is currently supported by the mobile devices. That information could be provided 
by the mobile device operator and/or the mobile device manufacturer, in the user documentation or online. Users shall 
also be able to get information on which functionalities and features are accessible through the standardized AT 
commands that are supported by the assistive device so that they can be aware of the degree of compatibility. The 
standardized AT commands should be available on request from the supplier. 

User needs 

Goal 6.2.a: Users should be free to choose a mobile device based on the functions they want, rather than on its 
adaptability. 

Requirement 6.2.b: All mobile devices shall be adaptable for use by people with disabilities. 

Goal 6.2.C: Any functionality and feature provided in mobile devices should be operable by standardized AT 
commands. 

Goal 6.2.d: The users should be able to buy a new mobile device and trust that their AT command compatible assistive 
devices will work. 

Requirement 6.2.e: The mobile device providers shall provide information, easily accessible to all (e.g. online), on 
which functionalities and features are accessible through standardized AT commands that are currently supported by 
their mobile device. 

Requirement 6.2.f: The assistive device providers shall provide information on which functionalities and features are 
accessible through standardized AT commands that are currently supported by their assistive devices. 

Requirement 6.2.g: The implemented standardized AT commands shall be available on request from the supplier. 

6.3 User advocates 

Many people with disabilities are dependent on advocates and carers to mediate on their behalf in many of the practical 
aspects of their daily lives. Not only do these advocates mediate in the dialogue between the disabled person and other 
agencies, they may also act as a common voice for a group of people with disabilities. In the case of users of mobile 
devices and services, these advocates and carers may be involved in both the specification and selection of devises, and 
assist in the use of the devices, acting as a communication channel between the user and the device or service. Users 
with disabilities want to have personal control of their communication, so, as the ability to adapt devices and services 
improves, the role of user advocates will change to focus on assisting in the specification and selection of appropriate 
technologies rather than being mediators of communication. They will, however, continue to have an important role in 
the process of collecting the requirements of individuals in terms of scoping the size and generic needs of this market 
sector. 



6.4 Developers of assistive devices 



The assistive device developers belong to an important stakeholder category, as their goal is to provide end-users with 
useful assistive devices. 

Many of the manufacturers have, or are planning, products connected to mobile devices. They can be divided into two 
categories: 

1) Those who only connect an "unintelligent" device to the mobile device, for example buttons of different types. 

2) Those who connect "smart" devices to the phone to use its phone functions and features, for example a Braille 
line. 

Category one all use a simple serial interface or an USB interface to connect to the mobile device. They use a simple 
approach where a change in voltage generates a hardware interrupt in the mobile device. There is no need for any 
"intelligence" in these devices. 
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Category two all connect to the mobile device using AT commands over cable or Bluetooth®. The assistive device 
developers are concerned about the poor implementations of the standard AT command set in the mobile devices. 
Therefore, the assistive device manufacturers are forced to confine their customers to specific mobile device models. 
Also, they all employ AT commands for very basic tasks such as making and receiving calls and SMSs. 

The availability of standardized AT commands, which are implemented in the mobile devices, is a crucial factor for 
developing assistive devices at affordable prices. This information can be obtained as an answer to an inquiry (by using 
an AT command) to the mobile device, but that requires the assistive device developer to acquire each mobile device. It 
would be useful to get the set of implemented standardized AT commands for each of the mobile devices, without 
having to acquire each of them. 

6.5 Manufacturers of mobile devices 

Manufacturers of mobile devices forms a very important stakeholder category, as without their ability and willingness 
to implement the standardized AT command set, the assistive device developers will not be able to develop affordable 
assistive devices, which can be used together with a range of mobile devices. As the manufacturers develop new 
functionalities and features, the future development of new standardized AT commands will be dependent on the 
manufacturers to contribute to the rapid development of the AT commands for the new functionalities and features. 



6.6 Network operators 



Users of mobile devices often procure those devices as a bundle together with a network access contract from a network 
operator. The devices procured in that way may have operator specific functions or user procedures in addition to those 
implemented by the manufacturer. These changes may involve AT commands as they may provide an alternative user 
interface to phone functions that are accessed through AT commands. A published comprehensive set of AT commands 
would assist this stakeholder to provide these alternative branded interfaces, and will ensure that they are implemented 
with different interfaces for different users (icons, text, speech, etc.). 



6.7 Service providers 



Mobile devices are increasingly being used to access online services that integrate phone functions with remote 
functions. These include, for example, online photo stores, location based services, and integrated interpersonal 
communication services. These service will make use of a variety of AT commands, perhaps mediated by the operating 
system on the device. 

6.8 Standardization bodies 

The present document will provide input to further standardization work. 3GPP is the standardization body responsible 
for the standardization of AT commands in the mobile arena [2] and [3]. There are however other standardization 
bodies with an interest in mobile devices and /or AT commands. 



6.9 Policy makers 



The regulatory authorities are charged with enacting the policies that are determined at a regional or national level. 
Policies set the broad framework of what it is that the society wants from its mobile systems infrastructure and the 
nature of the operations of that infrastructure. The regional and national regulators then determine the measurable limits 
of these policies in terms of operational parameters. The regulators are unlikely, however, to formulate and enforce a 
regulation without first being directed to do so by a policy making body. In the case of services for people with 
disabilities, issues of interest to policy makes, in addition to promoting healthy device and communications industries, 
are topics such as universal access rights and the provision of cost effective special devices and services. 
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6.10 Regulatory authorities 



The regulatory authorities implement the policies determined at the regional and national levels. Within this remit, they 
also deal with issues related to disable people (among others). In order to provide an eSociety for all, the disabled 
should not be excluded from the usage of ICT services and devices. The general principles and recommendations, listed 
in the report from the inclusive communications (INCOM) subgroup [30], comprise the following: "Where general 
production cannot facilitate universal access, manufacturers should ensure standardized, simple connectivity between 
their products and assistive technologies". The availability of a complete set of standardized AT commands for 
functionalities and features that are implemented on the mobile devices, it is important to achieve that goal. 

6.11 Emergency services 

In order for all individuals to be able to contact the Emergency services, this group of stakeholders have provided input 
and requirements to the present document. However, as their input is very useful and has a general interest not only in 
emergency situations, but in a range of situations, requirements and input from the Emergency services can be found 
among the other requirements. 

6.12 Relationships between stakeholders and technology 

The relationships between the various stakeholders and the technologies has been tentatively modelled in the following 
figure. This illustrates the dependencies of the interests of the various stakeholders, and the way that they influence each 
other. Subsequent development of new AT commands should reflect the interests of this full spectrum of stakeholders. 
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Figure 1 : Relationships between the stal<eholders and the technologies 

6.13 Requirements for satisfying the needs of the users 

The following requirements summarizes the previous clauses. 
Standard related requirements for satisfying the users" needs 

Requirement 6.13.a: To satisfy the needs of the users, it is necessary that the standard(s) ensure(s) that: 

1) Standardized AT commands are available to permit the implementation of the control of all functionalities and 
features in mobile devices from an external device. 

2) Information about new functionalities and features are provided for standards developers, thus allowing as soon 
as possible, the standardization of AT commands for the new functionalities and features. 
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Mobile device related requirements for satisfying the users" needs 

Requirement 6.13.b: To satisfy the needs of the users, it is necessary that the mobile devices ensure that: 

1) Any functionahty and feature provided in mobile devices should be operable by standardized AT commands. 

2) Accessible information should be provided with customized mobile devices, on which functionalities and 
features are accessible through standardized AT commands. 

3) Customized mobile devices shall ensure that the accessibility functionalities are unaltered, or enhanced. 

Assistive device related requirement for satisfying the users" needs 

Requirement 6.13.c: To satisfy the needs of the users, it is necessary that the assistive devices ensure that: 

1) Assistive devices should implement all necessary AT commands required to support the provision of any 
functionality and feature provided in mobile devices that should be operable through standardized AT 
commands. 

2) Assistive devices should be able to be used together with a range of mobile devices. 

3) The assistive device providers shall provide information on which functionalities and features in mobile devices 
can be controlled with their device. 

4) The assistive device providers shall provide, on request, information (e.g. online) on which standardized AT 
commands are implemented in their assistive devices. 



7 Gap analysis 

7.1 Introduction 

In order to identify the gap between what is available and what is the needed, an analysis has been performed in order to 
investigate whether additional standardized AT commands are needed. 

The gaps were identified in two ways: 

• By comparing the functionality of a typical mobile device with available AT commands. 

• By comparing the needs of users with disabilities with available AT commands. 

The needs of users with disabilities, as well as the need for new standardized AT commands, were identified through 
stakeholder input such as questionnaires, interviews, emails and workshops. 

The annexes provide further details on how the requirements have been collected and how the gap analysis has been 
performed. Annex B provides the questionnaires. Annex C provides details on issues related to various mobile devices. 
The input to the gap analysis of the functionalities of mobile devices versus standardized AT commands is summarized 
in annex D. 

There are, in principle, three types of gaps concerning AT commands: 

Complete: A complete gap indicate that there is no AT command available at all. 



• 



• Standardization: A standardization gap occurs when there are proprietary AT commands available for 
specific functionalities implemented on the mobile device(s), but there is no corresponding standardized AT 
command. 

• Implementation: An implementation gap occurs when a standardized AT command for a specific 
functionality is not implemented on a specific mobile device. A proprietary AT command for a specific 
functionality may, or may not, be implemented on the specific mobile device within a manufacturers" 
portfoho. 

In practice, the functionalities listed below as a implementation gap, depend on mobile device type. Some of the 
functionalities described below as standardization gaps, may for some mobile device types, not have any proprietary AT 
commands and could therefore be considered as belonging to clause 7.2. 
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7.2 Complete gaps 



Comparing the functionality of a typical mobile device with the available standardized or proprietary AT command sets, 
the gaps described in the following sub-clauses were found. More details on the gap analysis is provided in annex D. 

7.2.1 Colour 

Visually impaired people often find it easier to read if a specific text and background colour is used. Many dyslexic 
people find it easier to read when the text is on a background with a specific colour. 

7.2.2 Cursor control 

Mobility-impaired users may need alternative pointing devices (e.g. stylus, fmger, head pointer) to control the on-screen 
cursor. 

7.2.3 Font size 

Small visual details on the interface of mobile devices causes problems for people with visual impairments. They may 
need the option to change the font size. 

7.2.4 Menu 

The use of menus is the main difficulty for visually impaired people [34] when using a mobile phone. For blind people, 
it is almost impossible to use menus unless they learn them by heart, but being able to listen to spoken menus would 
help them using their mobile phones. AT commands providing this functionality will give the disabled user the same 
possibilities of controlling the mobile devices as a non-disabled user. 

Currently, the personalization of menus in mobile phones is very poor. Factors that could be subject for personalization, 
relevant for users with disabilities include the size of menu text, mode (text or spoken menus), colours of text and 
background. 

7.2.5 Radio 

The radio (e.g. FM) functionality incorporated in mobile phones is becoming increasingly popular and also the users 
with disabilities desire to be able to use this functionality. 

7.2.6 Screen 

People with vision impairments often find the screens of mobile devices too small and many have problems reading the 
texts and seeing the content. The "send screen dump" functionality could send the screen dump from the mobile device 
to the assistive device, where it can be presented in a larger size. It is also useful, in some situations, to be able to rotate 
the screen of the mobile device to better accommodate the contents of the screen. 

7.2.7 Speech-to-text 

Using a mobile device or an assistive device can be very time consuming. To simply be able to completely control the 
mobile device, speech-to-text may be required by some users. 



7.2.8 Text telephony 



Hard of hearing or deaf people have traditionally used text telephony for communication. Recently, mobile text 
telephony services have been made available. These provide a good option for hard of hearing and deaf users when 
there is no video telephony available or for those who do not know sign language. This new and essential functionality 
must also be made available through a mobile assistive device for hard of hearing and deaf users who are unable to use 
a mobile phone. 
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7.2.9 Text-to-speech 



Hard of hearing, deaf or visually impaired users will find it very useful to be able to use the Text-To-Speech (TTS) 
functionality. Being able to play text would be very useful for people with speech impairments. For people who are 
visually impaired, it is vital to be able to listen to for example an SMS. An AT command for this functionality is 
essential. 

7.2.10 Time-out 

The analysis of user requirements, have showed that users with reduced dexterity or visual impairments have problems 
using most types of mobile devices for various reasons including poor haptic feedback and tiny interface buttons. To 
enable a larger portion of the population to use mobile devices, an AT command for a longer time-out period for many 
functions is required (see also TR 102 068 [7]). 

7.2.11 Video telephony 

For users who are hard of hearing or deaf, mobile video telephony increases the quality of life because it enables these 
users to have a conversation anywhere with someone in sign language. Hard of hearing or deaf users who are not able to 
operate a typical mobile phone must still be able to use this functionality. Currently, AT commands for rotating the 
screen and switching the viewed video to full screen mode are lacking. 

7.2.12 Volume 

Audio services (e.g. media players, FM radio) on mobile devices are increasingly popular and also users with 
disabilities desire to use that functionality. Users shall be able to change the volume of media played on the mobile 
device from their assistive device. 



7.3 Standardization gaps 



Manufacturers have extended the AT command set in a proprietary manner as functionality has been added to mobile 
devices that was not anticipated when the initial standardized set was agreed. As many of these functions are of interest 
to users with disabilities, the proprietary commands and new functionalities and features shall be standardized as soon 
as possible in order to provide a generic platform. If this is not done, the cost of adaptation of assistive devices will 
remain high, and the development time will remain long. And in addition, the user will be constrained to a small 
selection of mobile devices. 

The following mobile device functionality are not covered by standardized AT commands, but there are existing 
publicly available proprietary AT commands, for one or more mobile device types. 



7.3.1 Applications 



An increasingly amount of applications are either included in the mobile device at purchase, or they can be included at 
any time. Also people with disabilities needing assistive devices may wish to use these applications. However, the use 
of application functionality at a content and information level is beyond the scope of the present document, but a 
minimum requirement is that all applications shall provide input, output and control functionality that is usable by all 
users. 

7.3.2 Audio stream 

For people with speech impairments, feeding an audio stream from an external assistive device to the mobile device is 
necessary. This will enable a person with a speech impairment to have a normal text conversation using a synthetic 
voice from an external device. 

7.3.3 Calendar 

Another function where a standardized AT command is lacking, is the calendar, which is a function most non-disabled 
people take for granted. 
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7.3.4 Camera 

The camera functionality incorporated in mobile phones is becoming increasingly popular and also the users with 
disabilities desire to be able to use the camera functionalities. 

7.3.5 Location services 

Visually impaired people and those with cognitive impairments such as dementia with reduced memory, may often 
encounter difficulties to locate where they are and where they are going. The use of location services (e.g. using GPS 
and base station triangulation) can therefore be very useful for these users. 

7.3.6 Messaging 

People with hearing impairments and those with speech impairments are particularly interested in using messaging 
services. AT commands for SMS are standardized (TS 127 005 [3]), but there are no standardized AT commands for 
MMS. 



7.3.7 Voice cinannel input and output 



Users who are hard of hearing and depend on an assistive device, may want to connect their hearing aid directly to the 
assistive device (and not to the mobile phone). 

Users who are speech impaired and use an assistive device to amplify their speech, or use their assistive device to speak 
for them will also benefit from connecting their assistive device directly to the mobile phone and use their assistive both 
for audio input and output. 



7.4 Implementation gaps 



Stakeholder input from assistive device manufacturers clearly indicate the need for better implementations of the 
standardized AT command set (TS 127 007 [2]). The implementations need to be complete, that is implement the full 
standardized AT command set. Better implementations would enable assistive device manufacturers to offer a wider 
range of mobile devices to their customers and it would also reduce the development costs, making assistive devices 
cheaper. 



8 Recommended solutions 



Currently, the mobile devices do not support all standardized AT commands. This also applies to assistive devices. In 
addition, a complete set of standardized AT commands corresponding to the full functionality of the mobile devices do 
not exist. Therefore, the assistive devices must support a multitude of variants of the mobile devices. This leads to an 
increasing complexity of the assistive devices and high development costs. If instead, standardized AT commands were 
always used, the development complexity and cost would be lower. Annex G describes general requirements related to 
the development of mobile devices in order to facilitate the development and use of assistive devices. Annex H presents 
specific requirements and the need for AT commands to support those requirements. 
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Annex A (informative): 
Requirement summary 

A.1 Stakeholders 

User needs 

Goal 6.2.a: Users should be free to choose a mobile device based on the functions they want, rather than on its 
adaptability. 

Requirement 6.2.b: All mobile devices shall be adaptable for use by people with disabilities. 

Goal 6.2.C: Any functionality and feature provided in mobile devices should be operable by standardized AT 
commands. 

Goal 6.2.d: The users should be able to buy a new mobile device and trust that their AT command compatible assistive 
devices will work. 

Requirement 6.2.e: The mobile device providers shall provide information, easily accessible to all (e.g. online), on 
which functionalities and features are accessible through standardized AT commands that are currently supported by 
their mobile device. 

Requirement 6.2.f: The assistive device providers shall provide information on which functionalities and features are 
accessible through standardized AT commands that are currently supported by their assistive devices. 

Requirement 6.2.g: The implemented standardized AT commands shall be available on request from the supplier. 

Mobile device related requirements for satisfying the users" needs 

Requirement 6.13.a: To satisfy the needs of the users, it is necessary that the standard(s) ensure(s) that: 

1) Standardized AT commands are available to permit the implementation of the control of all functionalities and 
features in mobile devices from an external device. 

2) Information about new functionalities and features are provided for standards developers, thus allowing as 
soon as possible, the standardization of AT commands for the new functionalities and features. 

Mobile device related requirements for satisfying the users" needs 

Requirement 6.13.b: To satisfy the needs of the users, it is necessary that the mobile devices ensure that: 

1) Any functionality and feature provided in mobile devices should be operable by standardized AT commands. 

2) Accessible information should be provided with customized mobile devices, on which functionalities and 
features are accessible through standardized AT commands. 

3) Customized mobile devices shall ensure that the accessibility functionalities are unaltered, or enhanced. 

Assistive device related requirement for satisfying the users" needs 

Requirement 6.13.c: To satisfy the needs of the users, it is necessary that the assistive devices ensure that: 

1) Assistive devices should implement all necessary AT commands required to support the provision of any 
functionality and feature provided in mobile devices that should be operable through standardized AT 
commands. 

2) Assistive devices should be able to be used together with a range of mobile devices. 

3) The assistive device providers shall provide information on which functionalities and features in mobile 
devices can be controlled with their device. 
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4) The assistive device providers shall provide, on request, information (e.g. online) on which standardized AT 
commands are implemented in their assistive devices. 



A.2 Recommended solutions 

Implementation of standardized AT commands 

Requirement G.2.a: The standardized set of AT commands should be implemented in mobile devices and assistive 
devices, so that developers of assistive technology can provide generic solutions, thereby reducing cost and increasing 
the market for such products. 

Requirement G.2.b: The functionalities and features implemented by standardized AT commands in the mobile 
devices and assistive devices should be publicly available, e.g. on the Internet, so that it will be possible to avoid 
purchasing mobile devices that are incompatible with the users' assistive devices. 

New AT commands for new functionality 

Requirement G.3: Proprietary commands and new functionalities and features should be standardized , as soon as 
possible. 



A.3 Specific requirements for new AT commands 

Applications 

Requirement H.2.a: Users should be able to use the applications installed into the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.b: Users should be able to download and install applications into the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.c: Users should be able to invoke the applications on the mobile device, by the use of AT commands 
from an external device. 

Requirement H.2.d: Users should be able to operate the applications on the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.e: Users should be able to close down the applications on the mobile device, by the use of AT 
commands from an external device. 

Audio Stream 

Requirement H.3: Users should be able to feed an audio stream to and from the assistive device and the mobile device, 
by the use of AT commands from an external device. 

Calendar 

Requirement H.4.a: Users should be able to use the calendar, by the use of AT commands from an external device. 

Requirement H.4.b: Users should be able to read calendar objects, by the use of AT commands from an external 
device. 

Requirement H.4.c: Users should be able to write calendar objects, by the use of AT commands from an external 
device. 
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Camera 



Requirement H.S.a: Users should be able to use all the camera functionality associated with the phone, by the use of 
AT commands from an external device. 

Requirement H.S.b: Users should be able to select the camera function of the phone, by the use of AT commands from 
an external device. 

Requirement H.S.c: Users should be able to set the camera's operational parameters, by the use of AT commands from 
an external device. 

Requirement H.S.d: Users should be able to operate all the functions of the camera, by the use of AT commands from 
an external device. 

Requirement H.S.e: Users should be able to choose if they want to store photographs and video clips, by the use of AT 
commands from an external device. 

Requirement H.S.f: Users should be able to choose where to store photographs and video clips (e.g. on internal or 
external memory), by the use of AT commands from an external device. 

Requirement H.S.g: Users should be able to send the photographs and video clips immediately using one of the 
messaging services available on the phone, by the use of AT commands from an external device. 

Requirement H.S.h: Users should be able to attribute positional information available in the phone to the photograph, 
by the use of AT commands from an external device. 

Colour 

Requirement H.6.a: Users should be able to set their preferred font colours, by the use of AT commands from an 
external device. 

Requirement H.6. b: Users should be able to set their preferred background colours, by the use of AT commands from 
an external device. 

Cursor control 

Requirement H.7: Users should be able to interact with alternative pointing devices, by the use of AT commands from 
an external device. 

Font size 

Requirement H.8: Users should be able to set font size, by the use of AT commands from an external device. 

Location services 

Requirement H.9.a: Users should be able to invoke the location functionality, by the use of AT commands from an 
external device. 

Requirement H.9.b: Users should be able to configure the operation of the location functionality, by the use of AT 
commands from an external device. 

Requirement H.9.c: User should be able to set the location services to time-out and switch them off, if inactive after a 
certain time, by the use of AT commands from an external device. 

Requirement H.9.d: User should be able to switch off the location services, by the use of AT commands from an 
external device. 

Menu 

Requirement H.10.2.a: Assistive devices should be able to present menus in alternative modes such as text or spoken 
menus, by the use of AT commands. 

Requirement H.10.2.b: Assistive devices should be able to display menus according to users" needs and preferences 
such as font size and colours, by the use of AT commands. 
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Requirement H.10.2.c: Users should be able to navigate either on their mobile device or on their assistive device, by 
the use of AT commands. 

Messaging 

Requirement H.ll.a: Users should be able to read, write and send MMS, by the use of AT commands from an external 
device. 

Requirement H.ll.b: Users should be able to read, write and send e-mails, by the use of AT commands from an 
external device. 

Radio 

Requirement H.12: Users should be able to invoke, configure the operate the radio (e.g. FM) on the mobile device, by 
the use of AT commands from an external device. 

Screen 

Requirement H.13.a: Users should be able to get a screen dump of their mobile device, for displaying it on their 
assistive device, by the use of AT commands from an external device. 

Requirement H.13.b: Users should be able to rotate the contents of the screen, by the use of AT commands from an 
external device. 

Requirement H.13.c: Users should be able to rotate the contents of the screen dump, by the use of AT commands from 
an external device. 

Speecin-to-text 

Requirement H.14: Users should be able to enable speech-to-text on their mobile device, by the use of AT commands 
from an external device. 

Text telepinony 

Requirement H.15: Users should be able to communicate using real time character by character text from an external 
assistive device, by the use of AT commands from an external device (EG 202 116 [1] and COCOM 04-08 [30]). 

Text-to-speecin 

Requirement H.16.a: Users should be able to enable text-to-speech on their mobile device, by the use of AT 
commands from an external device. 

Requirement H.16.b: Users should be able to set speech rate, by the use of AT commands from an external device. 

Requirement H.16.c: Users should be able to set spelling speed, by the use of AT commands from an external device. 

Requirement H.16.d: Users should be able to select how numbers larger than four digits will be read, by the use of AT 
commands from an external device. 

Requirement H.16.e: Users should be able to specify the natural language that is used by the text-to-speech 
functionality, by the use of AT commands from an external device. 

Time-out 

Requirement H.17: Users should be able to redefine the time for a range of time-outs, for various actions, by the use of 
AT commands from an external device. 

Video telephony 

Requirement H.18: Users should be able to view a video telephony call in full screen, by the use of AT commands 
from an external device. 
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Voice channel input and output 



Requirement H.19: Users should be able to connect the voice channel to an assistive device, by the use of AT 
commands from an external device. 

Volume 

Requirement H.20: Users should be able to set the volume of media played on the mobile device, by the use of AT 
commands from an external device. 
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Annex B (informative): 

Input and stakeholder contacts 

B.1 Introduction 

The present document has been developed based on desk based research and consultations with stakeholders. The first 
input was the results of the work of a previous ETSI STF that developed the TR 102 068 [7]. Stakeholder input have 
been collected in various ways including questionnaires, interviews, newsletters, emails and workshops. An important 
focus when collecting stakeholder input has been on consultations with users with disabilities and their representatives 
including disability related organizations. Potential stakeholders have been contacted at an early stage and been 
continuously informed (e.g. by newsletters), including people associated with disability related organizations such as 
RNIB (The Royal National Institute of Blind people). Disabled People's International, FITA - Foundation for IT 
Accessibility, The Swedish Handicap Institute, Cerebral Palsy - European Communities Association (CP-ECA), 
Disabled People's International, National Association for the Visually Handicapped, National Federation of the Blind, 
National Institute for the Visually Handicapped, Association of the blind and partially sighted of Slovenia, Swiss 
Central Association for the Blind, COST219ter and also, a wide range of assistive device developers have been 
contacted. Various disabilities have been addressed such as the visually impaired and blind, those with hearing 
impairments, deaf, motor impairments, speech impairments and cognitive impairments. 

The work has been presented and discussed at a range of events, including the following: 

Events 2006: 

• ETSI Technical Committee Human Factors: Milestone A (table of contents and scope) has been approved at 
HF#40, 16 June at ETSI. 

• Workshop, ICCHP 2006, 10th International Conference on Computers, Helping People with Special Needs: 
The workshop has been organized by ETSI STF 304 in association with the ICCHP 2006, 10th International 
Conference on Computers, Helping People with Special Needs, July 12-14, University of Linz, Austria. 

• Interviews with assistive device developers at ISAAC (International Society for Augmentative and Alternative 
Communication): Assistive device developers have been interviewed at the ISAAC (International Society for 
Augmentative and Alternative Communication) conference. The 12th Biennial International Conference of 
ISAAC was held on the 29-3 1st of July and the l-3rd of August in Dusseldorf, Germany. 

• Workshop, Rehabilitation and day centre in Upper Springland, Perth: People with various disabilities have be 
asked to give their opinions about tasks corresponding to different mobile technology usage scenarios. See 
clause B.2. 

• ETSI Technical Committee Human Factors: Milestone B (initial draft) has been approved at HF#41, 
22 September at ETSI. 

• The Swedish Handicap Institute: Presentation and discussion on the 1 1th of October 2006. 

• TCAM eWG on disability: Presentation and discussion at TCAM eWG on disability, 16-17th October at the 
European Commission, DG Information Society and Media, in Brussels. The main goal of the TCAM 
(Telecommunications Conformity Assessment and Market Surveillance Committee) meeting was to reach 
agreements to implement important features for accessible communication in mainstream communication 
products and services. 

Events 2007: 

• COST219ter conference: Short presentation and discussions on the 16''^ of January 2007 in London. 



• 



Joint ETSI USER group and HE meeting: Milestone D was approved. The meeting took place at 
NORMAPME in Brussels on the 20'^ of February 2007. 

ETSI HE interop: Presentation and workshop, on the 24-25 April at ETSI. 
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• 3GPP SA1#36: Coordination with 3GPP SAl working on Service and system Aspects. The meeting was on 
the 27th of April in Madrid. 

• 3GPP CT1#46: Coordination with the group responsible for TS 127 007 [2]. The meeting took place on the 
28* of Mars in Warsaw. 



B.2 Workshop 
B.2.1 Introduction 

ETSI STF304 (Specialist Task Force working on the present document) has organized a workshop on the 2^*^ of 
September 2006 at the Rehabilitation and day centre in Upper Springland, Perth in Scotland. The objective of the 
workshop was to involve people with disabilities in defining requirements and potential solutions for the adaptation of 
mobile devices for use by people with disabilities. 



B.2. 2 Usage scenarios 



Only people using the services at the Rehabilitation and day centre in Upper Springland were invited. Carers at the 
centre invited the people with disabilities and explained the goal of the workshop. 

The sessions consisted of six hands-on demonstrations where practical examples of typical use of mobile technologies 
could be tried by and discussed with the users. The sessions included: 

• Use of a WAP Browser: Example pages could include football, soap operas, social forums, E-Bay, games, 
video news. 

• Placing a conventional mobile phone call. 

• Use of a mobile system as an environmental control device (remote control), in this case it was used as a 
remote control of a TV and there was discussion about controlling other devices such as lamps. 

• The use of a mobile phone enabled "voice output communication aid" (a device that produces words and 
phrases when the user presses various buttons with symbols or letters) for making a phone call. 

• Freedom of Choice: The user were presented with a variety of mobile phones from which they could chose the 
one that they would select for themselves and then their choice was discussed. 

• A mobile phone was used to take a photo. 

The people with disabilities went from one station to the other, and the stations were supervised and observed by the 
ETSI STF experts, people from the University of Dundee and the staff from the Rehabilitation and day centre. The 
supervisors explained the usage scenarios and collected feed-back. 

B.2. 3 Discussions and conclusions 

The type and severity of disabilities varied. They included: 

• Motor impairment: e.g. difficulties in grasping and holding a mobile phone and difficulties in making precise 
movements with their fingers in order to press buttons or other type of interaction. In addition, many had 
wheel chairs as they could not walk (or had difficulties) because of their motor impairments and/or balance 
impairment. A mobile phone can be mounted on a wheelchair so that the user does not have to hold it in their 
hands. 

• Cognitive impairment. 

• Speech impairment. One person had a PDA attached to her arm and others had a "voice output communication 
aid" with software allowing them to press various buttons which produced words and phrases. 
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The requirements will therefore depend on every individual's specific needs and requirements. However, there are some 
general conclusions that could be drawn as a result of this workshop. 

• The users" abilities to use mobile devices can be improved by using assistive devices. 

• The people with disabilities may not have the same view on which is the most useful functionality, as non- 
disabled people. An example is that people with a cognitive impairment and/or speech impairment might not 
see the call/receive calls as the most interesting/useful functionality, but other functionalities might be more 
interesting to them such as: 

take a photo; 

listen to the radio; 

download and listen to music; 

use WAP and/or HTMS for looking up information (e.g. football scores); 

remote control. 



• 



For people with disabilities, there is not only a need for basic functionality supported by a limited set of AT 
commands, there is also a need for using a full range of functionalities on the mobile device and the AT 
commands to support this functionality. 

Conclusions of this workshop: the goal of the STF should investigate the full range of functionalities in order to suggest 
new AT commands (or related technology), where standardized AT commands are lacking. Also is it important that 
mobile device manufacturers implement standardized AT commands rather than appropriate AT commands so that 
assistive devices can be used with a wide range of mobile devices. There is a need to standardize new AT commands as 
soon as possible so that people with disabilities will not be discriminated in their possibility to use new functionality in 
mobile devices. 



B.3 Questionnaires 



The questionnaires have been developed with the aim to get input from relevant groups of stakeholders. The objective 
was to get qualitative input to our work so the questions were developed with the purpose to let the stakeholders freely 
express their opinions. There was no intention to perform any rigorous statistical analyse. 

The addressed groups of stakeholders are: 

users and user representatives; 

assistive device developers to be interfaced to mobile ICT; 

manufacturers of mobile ICT devices; 

regulatory authorities; 

standardization bodies; 

emergency services; 

employers of people with disabilities. 

The following questionnaires have been made publicly available on the ETSI web portal and they have also been used 
for interviews. 
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B.3.1 Users and User Representatives 

1) What mobile service do you want to use? 

2) Which of these services do you have difficulty using? 

3) Could you describe the difficulty that you encounter, particularly if you have problems using a specific device 
(Phone, PDA)? 

4) Would you like to use a particular assistive device with a mobile phone? 

5) In what way may users of assistive technologies encounter difficulties in using mobile phone in an emergency? 

6) Is there anything you would like to add/bring to our attention about the use of assistive devices with mobile 
phones? 

7) Would you (or your friends or colleagues) like to be kept informed about the progress of our work, and would 
you like an opportunity to provide input? 

B.3.2 Assistive Device Developers to be interfaced to mobile ICT 

1) What kind of assistive devices and applications are you developing, and specifically for the mobile 
communication market (e.g. GSM, GPRS, 3G, WiFi)? 

2) What type of communication protocol/hardware/software interfaces do you use to connect your technology to 
mobile ICT devices (Phone, PDA etc.)? 

3) What development environments do you use for developing the connection between your device and the 
mobile ICT devices? 

4) What problems might users encounter using your assistive devices with mobile ICT devices? 

5) What problems might users encounter using your assistive devices with mobile ICT devices in an emergency? 

6) Do you use AT Commands when using your assistive device with mobile ICT devices (Phone, PDA, etc.)? 

7) Do you plan to use AT commands in the future? If not, what methods do you intend to employ? 

8) Does the AT command set provide the functionality you need. If not, what additions/amendments to the AT 
command set would you like to see? 

9) Is there anything you would like to add/bring to our attention about the integration of assistive solutions with 
mobile ICT devices? 

10) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 

B.3.3 IVIanufacturers of mobile ICT devices 

1) Which mobile communication market (e.g. GSM, GPRS, 3G, WiFi) do you develop mobile ICT devices 
(Phone, PDA, etc.) for? 

2) What type of communication protocol/hardware/software interfaces do your mobile ICT devices support? 

3) What development environments do you recommend for integrating the assistive devices with your mobile 
ICT devices? 

4) What assistive applications are you aware of that are available for your mobile ICT devices? 

5) What assistive applications could you imagine would be useful for your mobile ICT devices? 

6) What problems might users of assistive technologies encounter if they attempt to use your mobile ICT 
technology in an emergency? 
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7) Do you support the fall AT Command Set (TS 127 007 [2]) in the connections or mobile applications on your 
devices? If not, which subset do you support? 

8) Do you plan to implement AT commands in future developments? If not, what methods do you intend to 
employ in the future? 

9) Does the AT command set (in TS 127 007 [2]) cover the set of commands that you wish to provide to assistive 
device developers? If not, what additions/amendments to the standard AT command set would you Uke to see? 

10) Would you be in a position to enhance the AT Command Set supported if it were extended to cover the 
integration of assistive technology with your device? 

11) Is there anything you would like to add/bring to our attention about the integration of assistive solutions with 
mobile ICT devices? 

12) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 



B.3.4 Regulatory Authorities 



1) Do the responsibilities of your organization cover the integration of assistive solutions with mobile ICT 
devices (Phone, PDA etc.) and services? 

2) What regulations do you administer or plan to administer that cover use of AT Commands in mobile ICT 
devices? 

3) Is it mandatory or optional to follow your regulations? 

4) Do your regulations cover the use of mobile ICT devices in emergency situations? 

5) Would you be prepared to administer any new regulations that may be devised to promote the integration of 
assistive technologies with mobile ICT devices? 

6) Is there anything you would like to add/bring to our attention about the integration of assistive solutions with 
mobile ICT devices within the regulatory framework? 

7) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 



B.3.5 Standardization Bodies 



1) In what way do the responsibilities of your organization cover the integration of assistive solutions with 
mobile ICT devices (Phone, PDA, etc.) and services? 

2) What standards do you administer or plan to administer that cover the integration of assistive solutions (e.g. 
involving the use of AT Commands) with mobile ICT devices? 

3) In which way is it mandatory or optional to follow your standards in this domain? 

4) Do your standardization activities cover the use of mobile ICT devices in emergency situations? 

5) Would you be prepared to promote any new standards that may be devised to promote the integration of 
assistive technologies with mobile ICT devices? 

6) Is there anything you would like to add/bring to our attention about the integration of assistive solutions with 
mobile ICT devices within the standardization framework? 

7) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 
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B.3.6 Emergency Services 



1) How do you deal with users of assistive devices attempting to request emergency assistance from your 

service? 

2) Are you required by regulation or law to provide the means for users of assistive devices to request access to 
your service? 

3) Have the advent of mobile phone services enhanced the set of possible ways for users to request emergency 
assistance from your service? 

4) Is there anything you would like to add/bring to our attention about the interaction with users of assistive 
devices who seek emergency assistance from your service? 

5) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 

B.3.7 Employers of Disabled People 

1) What mobile service should your disabled employees use to carry out their jobs? 

2) Do you expect your employees to use a specific mobile ICT device (Phone, PDA) as part of their job? 

3) Are you aware of any particular assistive devices being used with a mobile phone by any of your disabled 
employees? 

4) Have you as an organization encountered difficulties in providing any disabled employees with the necessary 
adaptations to enable them to use mobile ICT devices within their jobs? 

5) Is there anything you would like to add/bring to our attention about the use of assistive devices with mobile 
phones by your disabled employees? 

6) Would you (or your colleagues) like to be kept informed about the progress of our work, and would you like 
an opportunity to provide input? 
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Annex C (informative): 

Issues related to various mobile devices 

This annex provides an overview of the main issues that are encountered by users of mobile devices, set in the context 
of the different types of devices that they may be attempting or desiring to use. The following tables progress through 
the set of issues in a systematic sequence starting with the basic handling of the mobile device through to the need and 
practicalities of interfacing adaptations. 

Table C.l introduces the set of devices that are within the scope of the present document and the issues encountered 
when attempting to use them. 

Table C.1 : Description of devices used in the following tables 



Mobile Phone 


A device that is designed to enable voice calls to be placed and received as its primary function. It 
may have additional hardware functions (e.g. camera, mp3 player, FM radio) built in, a variety of 
additional services (text messaging, answer phone, WAP/Web browsing) and a variety of 
additional software (calendar, games, etc) 


Smart Phone 


This device is essentially a mobile phone (voice centric) with an enhanced feature set that includes 
functions normally found on a PDA, such as e-mail software, extensive address book, etc. 


PDA with built in 
Phone 


A personal digital assistant (data centric) with the ability to access the Internet via a GPRS or 3G 
mobile infrastructure. As a result of having this communication capability added to the PDA, it is 
also able to provide conventional phone services such as voice calling and text messaging. 


Phone Card 


A device that provides essentially only the radio part of a mobile phone. It is designed to be added 
to a platform such as a laptop computer. Additional software on the computer can then use this 
card as a communication channel for Internet services such as web browsing or e-mail, or can use 
the card to place and receive voice calls. 



Table C.2 shows the issues that users encounter when attempting to use these devices. 

Table C.2: General accessibility Issues 



IVIobile Phone 


The phones are too small for people with reduced dexterity (including most elderly people), and 

people with visual impairments to use. 

Users get lost in the functionality of the phone, and cannot navigate to the features they want to 

use. 


Smart Phone 


The same issues as for IVIobile Phones and PDAs with built in Phone are relevant also for Smart 
Phones. 


PDA with built in 
Phone 


Densely populated touch screens are difficult for people with reduced dexterity and visual 
impairments. 


Phone Card 


The call control and the usage control software is often poor and difficult to use. Alerts such as lost 
connections, etc. can be difficult to understand. 



Table C.3 highlights the general issues that have emerged concerning the use of services on these devices by users with 
disabilities 
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Table C.3: Accessibility issues for people with disabilities 



Mobile Phone 


The presentation of navigation and content text on the screen of these devices is often too 

small or of the wrong colour to be easily used. Users need to be able to adjust the font and text 

size. 

The time needed to manipulate certain function is longer than that allowed for by the "time-out" 

settings specified. These should be user controlled with appropriate phone and network control 

support. 


Smart Phone 


Same problem as for Mobile Phone. 


PDA with built in 
Phone 


Same problem as for Mobile Phone. 


Phone Card 


The software and set-up utilities that accompany these devices invariably require a level of 
understanding of mobile phone configuration that is deeper than that required to use the phone 
itself. The feedback to the user of network problems, and the action required to rectify them is 
often quite poor. This makes it difficult for therapists and users to set up and use these devices 
with their computing and communication devices. 



Table C.4 addresses "Telephony Functionality Accessibility". The core function of a mobile telephone (in whatever 
incarnation) is to place and receive voice calls. Some users require assistance to achieve this basic function. 

Table C.4: Telephony Functionality Accessibility 



Mobile Phone 


Adaptation by providing remote call control functions, or in the form of the means to present or 
take in speech and audio based content will be required. 


Smart Phone 


Same issues as for Mobile Phone and PDA with built in Phone. 


PDA with built in 
Phone 


The touch screen of a PDA can provide a useful space for interacting with the call control 
functions of the phone hardware. A key guard to direct a user's touch onto the active parts of the 
screen might be useful. 


Phone Card 


These functions are accessed via software on the host device, rather than by direct interaction by 
the user with the phone card. 



Mobile phone devices and platforms support a wide range of productivity software, addition devices and services. Users 
with disabilities have an interest in using these functions, but are often unable to do so, see issues described in table C.5. 

Table C.5: Additional services accessibility 



Mobile Phone 


The standard set of AT Commands do not cover basic in-phone services such as calendar, or 
hardware functions such as camera or mp3 player/radio (e.g.), although some proprietary sets 
do. Because of this, all adaptations are phone/adaptation specific. 


Smart Phone 


Same issues as those for Mobile Phone and PDA with built in Phone. 


PDA with built in 
Phone 


Some of the additional services found on some phones are also provided on PDAs (camera, mp3 
player) but are managed and controlled via the operating system in a way that is different to the 
control in phones. This adds to the range of adaptations requiring to be developed. 


Phone Card 


Control of the types of functions available on phones may be achieved using the preferred 
adaptation that the user has on their computing platform. Whilst this might address the 
accessibility concerns, this solution is unlikely to provide an equivalent mobile solution to a mobile 
phone. 



Table C.6 addresses "Accessibility device integration". One solution to the fact that the devices and the services that 
they support are not usable by people with disabilities, is to add an additional hardware or software function that enable 
the system to be used. This may take the form of an adaptation to an existing device such as a voice output reading 
menus for visually impaired people, or it may take the form of a dedicated adaptive system (such as a voice output 
communication aids) used by non-speaking people or people with speech impairments. 
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Table C.6: Accessibility device integration 



Mobile Phone 


The adaptation of the phone with additional hardware to control and pass data through the voice 
service is problematic because there is no standard method to do this. AT commands provide a 
useful middleware platform, but there is no obligation to implement even the standard set, so their 
availability cannot be guaranteed. 


Smart Phone 


Same issues as for Mobile Phone and PDA with built in Phone. 


PDA with built in 
Phone 


Because of the limited set of operating systems and indeed devices on the market, it may be 
feasible to adapt a device by having the OS mediate between the phone functions and the 
assistive software and hardware. AT commands would provide a standard middleware, as long 
as they are widely deployed. 


Phone Card 


As there are only a small set of "phone cards" on the market, it seems that it might be sensible to 
recommend specific cards to be used for providing a communication channel for assistive 
services on laptops of dedicated assistive devices. This assumption, however, reduces choice 
and is likely to increase the cost. The adoption of the comprehensive set of AT commands as 
standard in all the "phone cards" would ensure that any could readily be chosen and used in any 
device. 



Table C.7 addresses "Special services". Special services targeted specifically for people with disabilities could include, 
for example, text telephony for deaf people. These services have functionality beyond that offered by existing text 
chatting services. 

Table C.7: Special services 



Mobile Phone 


The mobile phone may be connected to a text-phone terminal to provide a communication path, 
or a service may be installed as software that handles the user interfaces and the call control. 


Smart Phone 


Same issues as for Mobile Phone and for PDA with built in Phone. 


PDA with built in 
Phone 


PDAs offer a more powerful computing platform for building assistive services. Because of the 
lack of standard AT command deployment, services will tend to be developed for specific 
devices. As the devices become obsolete, the service becomes unavailable. 


Phone Card 


Dedicated devices or special software running on a Laptop can be used via a "phone card". This 
has the same problem as above, namely that each instance of an adaptation is a unique 
development tied to a specific "phone card". 
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Annex D (informative): 

Mobile device functionality and their AT commands 

Table D.l lists functionalities of typical mobile devices and the related standardized AT commands. For some 
functionalities, standardized AT commands are missing. 

Table D.1 



Function Name 


Description 


Standardized AT Commands 


Account 
management 


Tools for managing the use of the mobile 
devices and the costs of service and 
application access and use. 


"+CNUM", VCAOC", "-I-CACM", "-i-CAMM", 
"+CPUC", "+CCWE" 


Address/Phone 
Book 


Manage and display address book entries, 
including speed dial configurations, and 
synchronization with external address books. 


"D", "-I-CPBS", 'VCPBR", "-I-CPBF", 'VCPBW", 


Answer 
Phone/Voice Mail 


Manage the storage and retrieval of answer 
phone messages. 


"+CRLP", VCSTA", "D", VCHUP", "-i-CBST", 
"+CR", VCEER", VCSNS", 'VCSVM" 


Applications 


Downloading, installation and use of 
applications. 


Not available. 


Calculator 


Enter data on the keypad and perform basic 
arithmetic functions for display on the screen. 


Not available. 


Calendar 


Manage and display calendar entries, and 
synchronization with other external calendars. 
(Mostly controlled by OBEX). 


"+CSDF" 


Camera 


Take, store, manage and distribute photos 
and video clips taken with the on-board 
camera. 


Not available. 


Clock 


Manage the display and configuration of the 
clock, including alarm functions. 


"+CSTF", VCCLK", "+CALA", "+CALD", 
"+CAPD", "-I-CTZU", "-I-CTZR", 


Device 
configuration 


Low level device management, including 
memory usage, battery usage, key 
assignment, etc. 


"+CPBS", VCSIL", VCPAS", VCFUN", 
"+CPIN", "+CBC", VCSQ", VCMEC", "-i-CKPD", 
"-I-CDIS", "+CIND", "+CMER", "+CSIM", 
"+CRSM", VCSCC", VCPWC", VCLAN", 
"+CLAE", VCSGT", 'VCRMC", 'VCRMP", 
"+CMAR", VCLAC", 'VCPROT", 'VCGLA", 
"+CRLA", VCCHO", "-I-CCHC", VCEAP", 
"+CERP", "+CUAD", VCMEE", "+CME ERROR" 


Device Connection 


Control and Configuration of device 
connection interfaces, including Bluetooth® 
and USB. 


Not available. 


E-Mail 


Read, compose, edit and store e-mail 
messages. 


Not available. 


Games 


Installation and playing of games, including 
hi-score and collaboration management. 


Not available. 


Location 


GPS and MBS location functions, showing 
location on a map, and sending location via 
other services (e.g. e-mail or SMS). 


Not available. 


Messages 


Manage the creation, editing, sending and 
storage of messages. 


"+CRC", "+CIND" 


Music Player 


Manage the loading, storage and replay of 
music files. 


Not available. 
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Function Name 


Description 


Standardized AT Commands 


Network 
Configuration 


Manage the selection of, and connection to a 
mobile network, including identification, 
closed user groups and multiparty calls. 
Includes Wireless LAN connection as well as 
GSM, GPRS &c. 


"+WS46", "+CREG", "+COPS", "+CLCK", 
"+CPWD", "+CLIR", "+COLP", "+CDIP", 
"+CCUG", "+CCFC", "+CCWA", "+CHLD", 
"+CTFR", "+CTFR", "+CSSN", "+CLCC", 
"+CPOL", "+CPLS", "+COPN", "+CAEMLPP", 
"+CPPS", "+CFCS", "+CAAP", "+CUUS1", 
"+CSQ", "+CIND", "+CGDCONT", 
"+CGDSCONT", "+CG 1 1- 1 ", "+CGQREQ", 
"+CGQMIN", "+CGEQREQ", "+CGEQMIN", 
"+CGEQNEG", "+CGATT", "+CGACT", 
"+CGCMOD", "+CGDATA", "+CGCLOSP 
(Obsolete), "+CGPADDR", "+CGAUTO", 
"+CGANS", "+CGCLASS" (GPRS only), 
"+CGCLPAD", (GPRS only), "+CGEREP", 
"+CGREG", "+CGSMS" 


Personalization 


Control of the personalization functions of the 
devices, including volume settings, rings 
styles and display themes. 


"+CNUM", "+CALM", "+CRSL", "+CVIB", 
"+CLVL", "+CMUT" 


Radio 


Tune and listen to radio programs (fm or 
Internet). 


Not available. 


Video Phone Gall 


Place, receive and participate in video calls, 
including call control and administration (caller 
ID etc, call forwarding, etc.) 


"+CSTA", "D", "+CHUP", "+CBST", "+CR", 
"+CEER", "+CRC", "+CSNS", "V.250", "+CIND" 


Voice Control 


Configuration and use of the Voice control of 
the phone functions. 


"+CIND" 


Voice Phone Call 


Place, receive and participate in voice calls, 
including call control and administration (caller 
ID etc, call forwarding, etc.). 


"+CSTA", "D", "+CHUP", "+CBST", "+CR", 
"+CEER", "+CRC", "+CSNS", "+CVHU", "V.250", 
"+CIND", "+CAJOIN", "+CAREJ", "+CAHLD", 
"+CAPTT", "+CAULEV", "+CALCC", "+CACSP", 
"+CANCHEV", "+COTDI", "+CGCS", "+CBCS" 


Web Browsing 


Access web based information, including the 
management of bookmarks. Includes the 
inputting of data into forms. 


"+CRLP", "+CSTA", "D", "+CHUP", "+CBST", 
"+CR", "+CEER", "+CSNS" 
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Annex E (informative): 

Suggested syntax of some required new AT commands 

This annex contains a sample of required AT commands and some examples of syntax that could be used to realise the 
command. It is not possible to prescribe a comprehensive set of new AT commands for any or all of the required 
commands as it is outside the scope of the present document. Furthermore, it was not possible to check any proposed 
new AT command against all sets of proprietary commands in use by the various device manufacturers in order to avoid 
conflict in command constructions. This annex, therefore, serves as a sample of the type of commands needed and the 
type of construction of these commands. 



E.1 Calendar 



E.1.1 Read 



Table E.I : +CCALR parameter command syntax 



+CCALR command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CCALR=<begin 
date>, <end date> 


+CCALR: 

<vCalendar>,<vCalendar>,<vCalen 
dar>,<vCalendar> OK 
+CCALR ERROR: <error code> 


Test command 


+CCALR=? 





Description 

The +CCALR command reads vCalendar objects. The result are the vCalendar objects between the <begin date>, 
and <end date>. 

Defined value 

<vCalendar>: vCalendar exchange format [6]. 



E.1.2 Write 



Table E.2: +CCALW parameter command syntax 



+CCALW command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CCAL=<vCalendar> 


+CCALW: OK 

+CCALW: ERROR: <error code> 


Test command 


+CCALW=? 





Description 

The +CCALW command writes vCalendar objects. 
Defined value 

<vCalendar>: vCalendar exchange format [6]. 
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E.2 Colour 
E.2.1 Font colour 

Table E.3: +CFCLR parameter command syntax 



+CFCLR command 


Command 


Possible response(s) 


Execution command: 


+CFCLR=<R>,<G>,<B> 


+CFCLR: OK 

+CFCLR ERROR: <error code> 


Read current font colour 


+CFCLR? 


+CFCLR=<R>,<G>,<B> 


Test command 


+CFCLR=? 





Description 

The +CFCLR command sets font/text colours. 

Defined values 

<R>: The value of the colour red, in the range of 0-255. 
<G>: The value of the colour green, in the range of 0-255. 
<B>: The value of the colour blue, in the range of 0-255. 

E.2. 2 Background colour 



Table E.4: +CBKG parameter command syntax 



+CBKG command 


Command 


Possible response(s) 


Execution command: 


+CBKG=<R>,<G>,<B> 


+CBKG: OK 

+CBKG ERROR: <error code> 


Read current bacl<ground colour: 


+GBKG? 


+CBKG=<R>,<G>,<B> 


Test command 


+CBKG=? 





Description 

The H-CBKG command sets background colours. 

Defined values 

<R>: The value of the colour red, in the range of 0-255. 
<G>: The value of the colour green, in the range of 0-255. 
<B>: The value of the colour blue, in the range of 0-255. 
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E.3 Cursor control 



E.3.1 Click 



Table E.5: +CCLIK parameter command syntax 



+CCLIK command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CCLIK=<X>,<Y>,< 
numberOfClicks >,< 
buttonNumber > 


+CCLIK: OK 

+CCLIK ERROR: <error 

code> 


Read command 


+CCLIK? 


OK 


Test command 


+CCLIK=? 


Max <X>, Max <Y>, Max 
<NumberOfClicks>, Max 
<buttonNumber> 



Description 

This command provides tlie option to click on a specific coordinate X, Y with alternative pointing devices. The clicks 
can be various numbers such as single click or double click. <numberOf Clicks> defines the number of clicks. 
<buttonNumber> defines what button is used for the click. 

Defined values 

<X>: integer; 

<Y>: integer; 

<numberOf Clicks>: integer; 

<buttonNumber>: integer. 



E.3.2 Move 



Table E.6: +CMOV parameter command syntax 



+CIVIOV command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CMOV=<X>,<Y> 


+CMOV: OK 

+CMOV ERROR: <error 

code> 


Read command 


+CMOV? 


OK 


Test command 


+CMOV=? 


Max <X>, Max <Y> 



Description 

The user should be able to move the cursor to a specific coordinate X, Y. This command can be used several times in 
order to show the motion. 

Defined values 

<X>: integer; 
<Y>: integer. 
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E.3.3 Drag 



Table E.7: +CDRG parameter command syntax 



+CDRG command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CDRG=<X>,<Y>, <status> 


+CDRG:OK 

+GDRG ERROR: <error code> 


Read command 


+CDRG? 


OK 


Test command 


+CDRG=? 


Max <X>, Max <Y>, Max <status> 



Description 

The user should be able to drag something with the cursor to a specific coordinate X, Y. This command can be used 
several times in order to show the motion. 

Defined values 

<X>: integer; 
<Y>: integer; 
<status>: 

startDrag 

1 moveDrag 

2 releaseDrag 



E.3.4 Example 



The following example shows a possible sequence of AT commands (in the order listed below): 

1) AT+CDRG=27, 39, (27 is X coordinate, 39 is Y coordinate and is startDrag) 

2) AT+CDRG=30, 42, 1 

3) AT+CDRG=35, 47, 1 

4) AT+CDRG=40, 52, 1 

5) AT+CDRG=45, 57, 1 

6) AT+CDRG=50, 62, 2 



E.4 Font size 



Table E.8: +CFSZ parameter command syntax 



+CFSZ command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CFSZ=<size> 


+CFSZ: OK 

+CFSZ ERROR: <error code> 


Read font size 


+CFSZ? 


+GFSZ=<size> 


Test command 


+CFSZ=? 





Description 

The +CFSZ command sets font size. 
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Defined value 

<size>: The preferred font size in pixels. 



E.5 Menu 



E.5.1 Notification of menu changes 



Table E.9: +CMEN parameter command syntax 



+CMEN command with sub-command 


Command 


Possible response(s) 


Execute command: 


+CMEN=<n> 


+CMEN:<menu id>, <menu name>, <highlighted 
item>, <item1>, <item2>,< item ...>,< itemN> 
+CMEN ERROR: <err> 


Test command 


+CMEN=? 





Description 

Set command controls the presentation of an unsolicited result code +CMEN : <menu id>, <menu name>, 
<highlighted item>, <iteml>, <item2>,< item ...>,< itemN>. 

Each time there is a change in the menu on the mobile, the unsolicited result code is sent to the assistive device. 

Defined values 

<n>: 

Turn off menu notification. 

1 Turn on menu notification. 

<menu id> : integer type; this is the unique identifier of the menu (more than one menu can have the same name, 
and it is therefore necessary to have a unique identifier). 

<menu name>: text string 

<highlighted item>: integer type; this is a number indicating which of the menu items is highlighted. The 
menu items are numbered from 1 to N. The value indicates that no item is highlighted. 

Each <item> consists of the following: 

<item>=<Tnenu item name> ,<menu item type>,<menu item value> 

<menu item name>: text string 

<menu item type> 

normal item (in plain text) 

1 radiobutton 

2 checkbox 

<menu item value> 

unticked 

1 ticked 

NOTE 1: The <menu item value> is only relevant when the <menu item type> is radiobutton or 
checkbox. 
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NOTE 2: Menus can be displayed as a list of items or as a set of icons on the mobile. However, the logical 
representation will remain the same as defined in the present sub-clauses. 

EXAMPLE 1: "Main menu", "Phone book", "text", "", "Messaging", "text", "", etc. 

EXAMPLE 2: "Ask to save", "On", "radio", "unselected", "Off, "radio", "selected". 

E.5.2 Navigating on the assistive device 

Table E.10: +CNMEN parameter command syntax 



+CNMEN command with sub-command 


Command 


Possible response(s) 


Execution command: 


+ CNMEN =<menu id>,<operation> 


+ CNMEN: OK 

+ CNMEN ERROR: <error code> 


Test command 


+ CNMEN=? 





Description 

The assistive device provides the mobile device with the user interactions when navigating in menus. 

Defined values 

<menu id> : integer type; this is the unique identifier of the menu (more than one menu can have the same name, 
and it is therefore necessary to have a unique identifier). 

<operation>: 

back to previous menu (if any). 

highlight next menu item. 

highlight previous menu item. 



select/change status of current menu item (e.g. select current menu item or tick check box or radio button if 
unticked). 



E.6 Screen dump 

Table E.11 : +CDMP parameter command syntax 



+CDMP command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CDMP= 


+CDMP: <Number of octets>,<file> 
+CDMP ERROR: <err> 


Test command 


+CDMP=? 





Description 

The "send screen dump" functionality sends the screen dump from the mobile device to the assistive device, that can 
then be presented in a bigger size which would benefit people with vision impairments. This functionality could be 
useful in a range of situations such as watching MMS or when navigating in menus (in case the assistive device cannot 
deal with the AT command for menus). This functionality should send still pictures, but these could be updated 
according to the needs depending on the situation. The assistive device may chose to update the screen (using 
+CDMP=) in intervals or according to the user's interactions. 

Defined values 

<Number of octets>: integer; 
<f ile>: string; 
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E.7 Speech-to-text 



Table E.12: +CSTT parameter command syntax 



+CSTT command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CSTT=<state> 


+CSTT: OK 

+CSTT ERROR: <err > 


Read command 


+CSTT? 


+CSTT: <state> 


Test command 


+CSTT=? 





Description 

The +CSTT command enables speech-to-text. 
Defined values 

<state>: 

Speech-to-text off 

1 Speech-to-text on 



E.8 Text telephony 
E.8.1 Sending text 

Table E.I 3: +CSTXT parameter command syntax 



+CSTXT command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CSTXT=<destination> 

<text mode> 
<Ctrl+Z/ESC> 


+CSTXT: OK 

+CSTXT ERROR: <err > 


Unsolicited result code: 


+CSTXT=<type> 




Test command 


+CSTXT=? 





Description 

In text mode, characters entered during the recommended time span of 300 ms are sent in UTF-8 encoded ITU-T 
Recommendation T.140 [19]. Both the previously mentioned solutions send digital text according to ITU-T 
Recommendation T.140 [19]. If text is available in a call it is indicated through the unsolicited result code 
H-CSTXT=<type>. 

Defined values 

<type>: 

1 real-time text according to IMS. 

2 text telephony over the voice channel and digitally. 
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E.8.2 Receiving text 

Table E.14: +CRTXT parameter command syntax 



+CRTXT command with sub-command 


Command 


Possible response(s) 


Unsolicited result code; 


+CRTXT=<source> 
<text mode> 


+CRTXT: OK 

+CRTXT ERROR: <err > 



Description 

In text mode, characters are received in ITU-T Recommendation T.140 [19]. 

E.8.3 Setting preference for real-time text 

Table E.15: +CRTXT parameter command syntax 



+CRTXT command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CRTXT=<state> 


+CRTXT: OK 

+CRTXT ERROR: <err > 


Test command 


+CRTXT=? 





Description 

Indication to the network if the real-time text medium should be set up or not (if it is available). 
Defined values 

<state>: Preference for real-time text. 

1 on 

off 



E.9 Text-to-speech 



Table E.I 6: +CTTS parameter command syntax 



+CTTS command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CTTS=<state> <speech rate> <spelling 
speed> <number option><language> 


+CTTS: OK 

+CTTS ERROR: <err > 


Read command 


+CTTS? 


+CTTS: <state> 


Test command 


+CTTS=? 





Description 

The H-CTTS command indicates to the network if the text-to-speech service should be set up or not (if it is available). 
Defined values 
<state>: 

Text-to-speech off 

1 Text-to-speech on 
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<speech rate>: 

Speed to n where n is increasing speed. 

N Highest speed (need to identify what number should replace n). 

<spelling speed>: 

Speed to n where n is increasing speed 

n Highest speed (need to identify what number should replace n). 

<number option>: 

Single digits; numbers longer than four digits can be read as single digits. 

1 Double digits; numbers longer than four digits can be read as double digits. 

2 Whole numbers, numbers longer than four digits can be read as whole numbers. 
<language>: 

Language Name of language, as specified in ISO 639-1 [4] and ISO 639-2 [5]. 

In order to specify the natural language that is used by the Text-To-Speech (TTS) functionality, the parameter language 
is used. It is defined as specified by the ISO standard for the "representation of names of languages", ISO 639-1 [4] and 
ISO 639-2 [5]. The language codes are based upon the concept of a set of basic languages together with variants based 
upon the country in which they are used (e.g. French used in France is coded as "fr-FR, and when used in Canada is 
coded as "fr-CA"). 

Further enhancements on multicultural and language aspects might be relevant to address in the future. These 
enhancements should be based on the guidelines and suggested future work described in EG 202 421 [8]. 



E.10 Time-out 



Table E.I 7: +CTOUT parameter command syntax 



+CTOUT command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CTOUT=<n> 


+CTOUT OK 

+CTOUT ERROR: <err > 


Read command 


+CTOUT? 


+CTOUT: <state> 


Test command 


+CTOUT =? 





Description 

The + CTOUT command multiplies all time factors with the factor n. 
Defined values 

<n>: multiply all time factors with the factor n. 



£75/ 



52 



ETSI TS 102 511 VI .1.1 (2007-08) 



E.11 Volume 
E.11.1 Media volume 

Table E.I 8: +CMVLM parameter command syntax 



+CMVLM command with sub-command 


Command 


Possible response(s) 


Execution command: 


+CI\/IVLI\/l=<volume> 


+CMVLM: OK 
+CMVLM ERROR: <err > 


Read command 


+CIVIVLIVI? 


Current <volume> 


Test command 


+CIVIVLIVI=? 


List of supported <volume> 



Description 

The +CMVLM command controls volume of media (e.g. FM radio). 
Defined values 

<volume>: integer type value with manufacturer specific range (smallest value represents the lowest sound level). 
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Annex F (informative): 
Technical background 

F.1 AT commands and associated technology 

F.1.1 AT commands 
F. 1.1.1 History 

The AT command set is also called Hayes command set, after the company Hayes Microcomputer Products, named 
after its founder Dennis Hayes. He designed his first "smart modem" in 1977 and identified the need to instruct the 
modem what phone-number to dial, using only one port. In order to solve that problem, Mr. Hayes developed Hayes 
command set. Before the "smart modems", which used the Hayes command set, users had almost no control over their 
data transmissions. Finally, thanks to the modems implemented with the Hayes command set, people could use the 
commands to configure a range of modem settings without having to make physical changes to the hardware, and they 
were able to easily perform tasks such as redialling numbers, troubleshooting data transmission errors, and adjusting the 
modem's speaker volume. The ITU-T V-Series "Recommendations for protocols that govern approved modem 
communication standards and interfaces" (e.g. ITU-T Recommendations V.250 [20] and V.251 [21]) are also using the 
Hayes AT command set format. 

AT commands, has matured from being a modem control technology to be a comprehensive and pervasive middleware 
platform for mobile devices. The present document refer primarily to the AT command set standardized by 3GPP 
(TS 127 007 [2]). 

F.I. 1.2 Overview 

AT commands are used to exchange commands and data between the mobile device and other devices. They can be 
used with a range of external devices such as accessories, assistive devices and devices in the intelligent home. The 
focus of the present document is on the exchange of commands and data with assistive devices. However, there will not 
be any particular AT commands for assistive devices in parallel with the existing set (and future additions to) of 
standardized AT commands. Instead, the set of additional AT commands, developed as a result of the requirements in 
the present document, should be treated as part of the ordinary standardized AT commands. 

AT commands provide functionality such as: 

• control of the mobile device (or modem), e.g.: 

configure the mobile device to connect via infrared port, Bluetooth® or the system bus; 
define settings and service access. 

• request information about the current configuration or operational status. 

• request information the mobile device if a specific AT command is implemented, and when applicable, request 
the range of valid parameters. 

AT is the two character abbreviation used to start a command line sent from a mobile device to an external device such 
as an assistive device. The following figure illustrating the basic structure of a command line is explained in detail in 
TS 127 007 [2]. 
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subparameter 



read command for checking 
current subparameter values 



command line prefix 



extended commands are 
delimited witfi semicolon 



command line 
termination cfiaracter 



ATCMD1 CMD2=12; +CMD1 ; +CMD2=„15; +CMD2?; +CMD2=?<CR> 



subparameters 

bas/c command may be omitted / 

(no + prefix) ex/ended command 

(prefixed with +) '®^' command for checking 

possible subparameter values 

Figure F.1 : Basic structure of a command line (TS 127 007 [2]) 

AT commands are generated by the operating system of the mobile device or by an external device to the radio 
hardware of the mobile device, see figure F.2. 
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Figure F.2: AT command flow in a mobile device 

when a user command on a mobile device 

generates an AT command 



Figure F.3: AT command flow when a user 

command on an external assistive device 

generates an AT command 



For example, if a user dials a number from the mobile device, the left illustration in figure 3 illustrates that the AT 
command is generated by the operating system and sent to the radio hardware. If on the other hand the user dials from 
an assistive device, the AT command is generated by the assistive device and sent to the mobile devices which forwards 
it to the radio hardware. There are also unsolicited result codes, they do not occur as a direct response to an AT 
command but to an event. An example is the RING indication, it is generated each time there is an incoming call. 

Regardless of the user command and source many of the actions a user can perform on a mobile device eventually end 
up with the operating system sending an AT command to the hardware. For more on AT commands on leading 
operating systems, see clause F. 1.3. 
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F.1.1.3 Implementation 



The AT commands standard (TS 127 007 [2]) defines for each AT command, under the keyword "Implementation" 
whether the command is "Mandatory" or "Optional". When relevant, the "Mandatory" requirement is followed by a 
condition defining under which circumstances the command is mandatory. A typical condition would be: "If the 
functionality is supported" following a short description of the referred functionality. 

An identified problem for assistive device developers is that many standardized AT commands are not implemented in 
the mobile devices. It is common that some proprietary AT commands are implemented instead of the corresponding 
standardized AT command. 

Some manufacturers provide publicly available documentation on supported standardized AT commands and 
proprietary AT commands that are implemented in their mobile devices. 

F.1.1.4 Groups of AT commands 

Currently, there are no specific AT commands for assistive devices. The AT commands are grouped by 3GPP in two 
major groups reflected by the source documents: 

• AT command set for User Equipment (UE), Use of Data Terminal Equipment - Data Circuit terminating 
(TS 127 007 [2]). 

• Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) 
(TS 127 005[3]). 

The present document is focusing on the AT commands used in the User Equipment (TS 127 007 [2]), which has the 
following groups of AT commands: 

general commands: used for identification of TAs; 

call control commands and methods; 

network service related commands; 

mobile termination control and status commands; 

mobile termination errors; 

commands for packet domain; 

commands for VGCS and VBS (voice broadcast and group call services). 

There will not be any particular AT command standards for assistive devices in parallel with the existing set (and future 
additions to) of standardized AT commands. Instead, the set of additional AT commands, developed as a result of the 
requirements in the present document, should be treated as part of the ordinary standardized AT commands. 

F.1 .1 .5 Mobile device functionality and their AT commands 

The following non-exhaustive list provides examples of functionality supported (at least partially) by standardized AT 
commands (TS 127 007 [2]): 

account management; 

address/phone book; 

answer phone/voice mail; 

calendar; 

clock; 

device configuration; 

messages; 
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network configuration; 

personalization; 

video phone call; 

voice control; 

voice phone call; 

web browsing. 

The gap analysis described in clause 7 maps the requirements by the users on to a number of AT commands. Annex H 
lists the identified requirements where there are no standardized AT commands, and describes those new AT commands 
that will be fed into an appropriate AT commands standard. 

F.1 .2 Complementary Technology to AT commands 

The operating systems and Java^^ implementations also provide functions to do similar tasks that can be done with AT 
commands. Below is a brief description of some environments and how AT commands are used in them. 

NOTE: Symbian OS^m, Microsoft ©Windows Mobile, Qualcomm's BREW'"^, Java'"^ are examples of a products 
available commercially. This information is given for the convenience of users of the present document 
and does not constitute an endorsement by ETSI of these products. 



F.1.2.1 Symbian OS 



TM 



Symbian OS^^ [32] is used in a significant proportion of mobile devices. SymbianT"^ provides a generic telephony 
module consisting of: 

• Telephony Sub sYstem (TSY); 

• Comms Server protocol (CSY); 

• Network InterFace (NIF). 

The telephony module communicates with the GSM modem using standard AT commands (see figure F.4). The 
telephony module can be adapted by the mobile device manufacturer to support other functionality either through AT 
commands or through some other proprietary interface. 
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Figure F.4: Symbian OS™ architecture 
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F.1 .2.2 Microsoft ©Windows Mobile 

The Microsoft ©Windows Mobile operating system is used in many mobile devices, particularly high-end devices. The 
system architecture [33] in Microsoft ©Windows Mobile is layer based where the layer communicating with the GSM 
modem is called the Radio Interface Layer (RIL). Each mobile ICT manufacturer has to implement their own RIL. The 
RIL sends AT commands to the GSM modem and processes the responses (see figure F.4). The RIL can also be made 
to handle other proprietary methods of communication with the hardware. 

Microsoft ©Windows Mobile also accepts AT commands from the user. These commands are handled by the AT 
Communication Interface (ATCI). The ATCI sends these commands through the RIL to the GSM modem. 
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Figure F.5: Microsoft ©Windows IVIobile 5 system architecture 



F.1.2.3 Qualcomm's BREW 



TM 



BREW^'^ (Binary Runtime Environment for Wireless) [35] is a proprietary development platform originally built for 
Qualcomm's'*^ CDMA phones. It runs between the application and the operating system of the phone. Software can be 
built for BREW'^ using C++ and Java''^. The software is easily portable between different types of phones running 
different operating systems as long as they support BREWT"^. 



F.1.2.4 Java 



TM 



Java''"^ is a software platform available in most modern mobile devices. Java^"^ is implemented on top of the existing 
operating system (see figures F.4 and F.5) and has no direct support for sending AT commands to the mobile device. 
Rather, an AT command will be generated by the operating system when a request is received through the Java'"^ 
implementation on the mobile device [32] and [33]. 



F.2 Data transfer technologies 
F.2.1 lntro(duction 

The AT commands remain the same whether cable or wireless technology (e.g. Infrared, Bluetooth©) is used for data 
transfer. The built-in modem in a mobile device can be accessed via various technologies such as Infrared or 
Bluetooth© wireless technology, USB cable or RS232 cable connection. 

IrOBEX (Infrared Object Exchange) provides the exchange of arbitrary data objects (e.g. vCard, vCalendar, 
applications) between devices equipped with infrared. 
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F.2.2 Bluetooth® 



Originally developed by Ericsson, Bluetooth® [17] and [18] is now used in many different products, by many 
manufacturers. Bluetooth® can be used as a cable replacement to connect and exchange information between devices 
such as assistive devices, mobile devices, headsets, PCs, laptops, digital cameras, video game controllers, mobile 
handsfree. Up to eight devices can be connected simultaneously. 

Bluetooth® does not require line of sight between communicating devices, so the walls in a house do not stop 
Bluetooth® signals. Thus, it is useful in intelligent homes for connecting and controlling several devices in different 
rooms. In addition, Bluetooth® is also used for Car Area Networks (CANs). 

The operating range depends on the device class: 

• class 1: primarily for industrial use - have a range of 100 m; 

• class 2: most often in mobile devices - have a range of 10 m; 

• class 3: up to 1 meter. 

Bluetooth® uses short range radio frequency and the radio is typically built into a small, low-cost microchip with very 
low power consumption and has become popular as it enables low-cost implementations. Bluetooth® operates in the 
unlicensed Industrial, Scientific and Medical (ISM) band at 2,4 GHz to 2,485 GHz, using a spread spectrum, frequency 
hopping, full-duplex signal at a nominal rate of 1 600 hops/sec. 

Bluetooth® is divided into several standardized profiles [18], where each profile has a specific area of use, e.g. the 
Hands-Free Profile (HFP). To communicate between two devices using a specific profile, both parties must support it. 
Below is a short description of the standardized profiles which are most interesting from an accessibility viewpoint: 

• File Transfer Profile (FTP): Provides access to files on the device and uses OBEX. 

• Human Interface Device Profile (HID): Provides support for devices such as joysticks, mice and keyboards. 

• Phone Book Access Profile (PBAP): Allows exchange of Phone Book objects between devices. 

• Serial Port Profile (SPP): Based on the TS 101 369 [10], this profile emulates a serial cable to allow RS232 
interfaces to be replaced with Bluetooth®. 

F.2.3 Infrared - IrDA 

The Infrared Data Association, often referred to as IrDA [16] is a non-profit industry consortium which defines a set of 
globally adopted short range infrared (Ir) communications standards. Infrared (IR) is electromagnetic radiation of a 
wavelength shorter than that of radio waves, but longer than that of visible light. 

A disadvantage with IrDA, compared to Bluetooth®, is that the devices must have a direct line of sight in order to 
communicate via IrDA. 

IrDA has produced many technical specifications, such as: 

IrPHY, Infrared Physical Layer Specification (mandatory) is the lowest layer of the IrDA specifications. 

IrLAP, Infrared Link Access Protocol (mandatory) is the second layer of the IrDA specifications. 

IrLMP, Infrared Link Management Protocol (mandatory) is the third layer. 

IrCOMM, Infrared Communications Protocol (optional) is the fourth layer. It lets the infrared device act like a 
serial or parallel port. 

Tiny TP, Tiny Transport Protocol (optional) lies on top of the IrLMP layer. Tiny TP is mandatory for IrOBEX. 

IrOBEX, Infrared Object Exchange (optional) provides the exchange of arbitrary data objects (e.g. vCard, 
vCalendar or even applications) between devices. IrOBEX lies on top of the Tiny TP protocol, which is 
mandatory for IrOBEX. 

IrLAN, Infrared Local Area Network (optional) for connecting an infrared device to a local area network. 
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• IrFM, Infrared Financial Messaging, is used for sending and receiving payment and transaction record 
information between mobile devices, for example mobile phones or PDAs and a financial terminal such as a 
Point-Of-Sales (POS). 

• IrSimple, a high-speed-infrared communications protocol for mobile devices that aims to deliver 100 Mbit/s 
data transfer rates. 

The IrDA standards are not uniquely defined so equipment from various manufacturers are not always compatible. 

F.2.4 OBEX 

OBEX (OBject EXchange) is a communication protocol for the exchange of data objects such as business cards, 
address book contacts, calendar data and files between devices. The OBEX standard [16] is specified by the Infrared 
Data Association (IrDA), see clause F.2.3 on "Infrared - IrDA". However, OBEX is not limited to use in an IrDA 
environment. It has also been adopted by the Bluetooth® Special Interest Group (see clause F.2.2 on "Bluetooth®") and 
OMA SyncML ( http://www.openmobilealliance.org/ ). 

OBEX is mediated by the "+CPROT" AT command. The OBEX protocol has a defined set of operations that is used for 
sending and handling data. It uses a client/server request-response model. The OBEX client initiates the connection to 
an OBEX server and starts the OBEX operations. The OBEX server waits for the OBEX client to initiate the connection 
and then responds to the OBEX operations. An OBEX session is started with the Connect operation and ended with the 
Disconnect operation. The client can invoke any number of operations between Connect and Disconnect. The OBEX 
protocol defines operations such as: 

• Connect: initiates the connection and sets up the basic expectations of each side of the link. 

• Disconnect: signals the end of the OBEX session. 

• Get: the client requests that the server sends an object to the client. 

• Put: sends one object from the client to the server. 

• Delete: removes an object from the server. 

• Setpath: sets the active directory on the server in order to enable transfers that need additional path 
information. 

• Abort: terminates a multi-packet operation (such as PUT) before it would normally ends. 

Information about the objects can be provided in headers. For example, a Put request is normally used with the Name 
and the Length header. There are headers such as: 

• Name header: a text string describing the name of the object to be handled (e.g. the filename "Mytext.txt"). 

• Type header: describes the type of the object (e.g. text, binary, vCalendar). Type is used for handling the 
object in an appropriate way. 

• Length header: the length of the object (in bytes). This can be used by the receiver to quickly terminate 
transfers requiring too much space, and to make progress reporting easier. 
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Figure F.6: OBEX activation 



F.3 Current mobile assistive devices 

Mobile assistive device manufacturers can be divided into two categories, manufacturers who implement their software 
inside the mobile device itself and manufacturers who make an external device with their own software on it. 

The first category uses the functionality provided by the operating system on their target device(s). For example such a 
device can be an external button connected to a mobile phone. In some cases, the button used a simple hardware 
interrupt on the serial interface to indicate a push of the button. This push was detect by the software on the phone, 
which performed the appropriate action using the operating system functions. 

The second category uses AT commands to communicate with the mobile device. Within the second category, the 
communication with the mobile device has been solved in three ways: 

• AT commands sent over a serial cable connected to a mobile phone. 

• AT commands sent over Bluetooth® to a mobile phone. 

• AT commands sent to a PC-card integrated in the assistive mobile device. 



F.4 The Universal Remote Console Standards 

The Universal Remote Console (URC) can be used for remote control of a great number of devices including mobile 
phones. The URC framework ( http ://mvurc . org/ ) has been released as a family of ISO standards in 2006, in 
ISO/IEC FCD 24752-1 [37] to ISO/IEC PCD 24752-5 [41]. It defines an XML-based, network-neutral framework of 
components for remote control of electronic and ICT devices and services. Conformant products can be controlled by 
any software or device implementing the URC technology, including voice-enabled controllers and assistive devices. 
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F.5 Application Toolkit for SIM, USIM and other cards 
F.5.1 Overview 

The SIM Application Toolkit (SAT) or simply SIM Toolkit (TS 101 267 [13]) provides mechanisms which allow 
applications, existing in the SIM, to interact and operate with any ME which supports the specific mechanism(s) 
required by the application. SAT is an ETSI/SMG standard developed within 2G for Value Added Services (VAS) and 
e-commerce using GSM mobile devices for making the transactions, such as checking the bank account and paying 
bills. The toolkit standard is further developed for 3G. 

The SIM card has a proactive role in the handset as the SIM initiates commands independently of the handset and the 
network. What is needed is a SIM Toolkit-enabled phone with an appropriate SIM Toolkit-specific SIM card which will 
provide much of the intelligence to make transactions over GSM. The SAT enables the SIM card to: 

• control the GSM mobile device interface; 

• access the network; 

• allow the end user to make an interactive exchange with network applications. 

F.5.2 Standards supporting 2G and 3G 

In 2G networks, the SIM Application Toolkit (SAT) is defined in TS 101 267 [13]. From release 4 onwards, 
TS 101 267 [13] is replaced by TS 131 1 1 1 [14] which also specifies the USIM Application Toolkit (USAT) for 3G 
networks. The Card Application Toolkit (CAT) (TS 102 223 [15]) is based on SAT, which is stripped of all the GSM 
specific features. The CAT provides mechanisms that allow applications, existing in the UICC, to interact and operate 
with any terminal which supports the specific mechanism(s) required by the application. 

F.5.3 AT command supporting SIM commands and application 
toolkits 

The functionalities of the cards are available through an AT command (h-CSIM) where all SIM commands, including 
the toolkit commands are encapsulated. 



F.6 Device Management 



The Open Mobile Alliance (OMA) Device Management standard, based upon OMA SyncML, is a useful tool as it 
provides means for configuring, managing, and updating mobile devices during the entire life cycle of the device and its 
applications [27]. 

As various applications such as e-mail, MMS, calendar, and games need specific configuration settings, many users find 
it difficult to configure their applications. However, users would not have to deal with the management of the software 
in their mobile devices. Neither do they need to go to the store for managing their mobile devices. Instead, Device 
Management can be used by operators and service providers, who can help their customers to start using new services 
and to effortlessly modify the configuration of existing ones. The operators and service providers can access the mobile 
devices via Internet and make a range of changes such as updating the mobile devices' software, handling debugging 
issues and installing new applications. 

For companies, a Device Management system provides benefits such as better control and safety as well as increased 
efficiency. Normally, employees would need to visit the IT department for updating their devices. With an increasing 
number of mobile devices in many companies, there is an increasing demand for managing, controlling and updating 
their devices easily "over the air". 
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Device management includes, but is not restricted to: 

• software installation; 

• setting initial configuration information in devices; 

• software and firmware updates; 

• subsequent installation and updates of persistent information in devices; 

• retrieval of management information from devices; 

• processing events and alarms generated by devices; 

• user preferences. 
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Annex G (informative): 
Recommended solutions 

G.1 High level requirement 

The general principles and recommendations, listed in the INCOM report [30] comprise the following: "Where general 
production cannot facilitate universal access, manufacturers should ensure standardized, simple connectivity between 
their products and assistive technologies". 



G.2 Implementation of standardized AT commands 

The set of AT commands provides the comprehensive and pervasive middleware platform for mobile technologies, in 
particular mediating between the mobile devices and external devices such as assistive technology. Because the full set 
of standardized AT commands is not necessarily implemented in any specific devices, it is impossible for assistive 
device developers to produce generic solutions that can be expected to work with any device that the disabled user 
would chose to use. The standardized set of AT commands should be fully implemented, so that developers of assistive 
technology can provide generic solutions, thereby reducing cost and increasing the market for such products. 

The set of implemented standardized AT commands used in the mobile devices should be publicly available, e.g. on the 
Internet, so that it will be possible to avoid purchasing mobile devices that are incompatible with the users' assistive 
devices. 

Implementation of standardized AT commands 

Requirement G.2.a: The standardized set of AT commands should be implemented in mobile devices and assistive 
devices, so that developers of assistive technology can provide generic solutions, thereby reducing cost and increasing 
the market for such products. 

Requirement G.2.b: The functionalities and features implemented by standardized AT commands in the mobile 
devices and assistive devices should be publicly available, e.g. on the Internet, so that it will be possible to avoid 
purchasing mobile devices that are incompatible with the users' assistive devices. 



G.3 New AT commands for new functionality 

There is a common problem that people needing to use assistive devices cannot use the latest functionalities and 
features implemented in mobile devices as the assistive devices cannot operate the new functionality. The reason is that 
standardized AT commands do generally not exists for recently developed functionalities and features. A common first 
step is that the companies develop proprietary AT commands. Therefore, standardizing as many proprietary AT 
commands as possible, would allow lower development costs of assistive devices as they would be compatible with a 
multitude of mobile devices. A requirement is to initialize the standardization work on new AT commands as soon as 
possible. 

New AT commands for new functionality 

Requirement G.3: Proprietary commands and new functionalities and features should be standardized , as soon as 
possible. 
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G.4 Related standardization work 

The present document lists new AT commands that are not limited to current standards, but may also put requirements 
for further work. For example, work will be needed on a variety of topics, including personalization and user profiles 
and multicultural communication in order to define preferences and needs in those areas. AT commands involving 
aspects that can be personalized may be affected by the use of user profiles (EG 202 325 [9]). Also, user profile 
management will in some way utilize AT commands. 

It is important to recognize that further standardisation work may also be needed at the operating system and application 
content levels, where applications are to be added to mobile devices, to ensure that they are constructed in a way that 
are both usable and accessible. Where application style guides exists for phones and operating systems, these need to be 
reviewed and extended to ensure that they cover accessibility, and where they do not exist, mobile device and operating 
system manufacturers and organizations should make it a matter of priority to develop one. The details of this work are 
beyond the scope if the present document. 

The use of Universal Remote Console (URC) specified in ISO/IEC FCD 24752-1 [37] to ISO/IEC FCD 24752-5 [41] 
(see clause F.4) should be considered in the further work. An interface for AT commands to the URC could also be 
developed. It could be done in two ways: 

1) On the URC: AT commands are sent to the target device. 

2) On the target: Some other command is sent to the target and is translated to the appropriate AT command in 
the target environment. 

If URC becomes a well adopted standard, URC could be useful for the assistive device developers. Approach 2 gives 
mobile phone manufacturers the possibility to implement a URC interface and hide their proprietary AT commands 
behind the URC interface. 
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Annex H (informative): 

Specific requirements for new AT commands 



H.1 Introduction 



Based on a gap analysis (see clause 7) where existing AT commands have been validated, this clause presents 
requirements and the new AT commands that should be available from assistive devices. 

In the friture, when the ETSI user profile activities have completed the standardization work on user profiles, it will be 
appropriate to have many preferences (related to the services described below) stored in the user profile 
(EG 202 325 [9]). 

Further details related to various mobile devices and identified issues and problems can be found in annex C. The 
suggested syntax of some required new AT commands can be found in annex E. 



H.2 Applications 



Some mobile devices provide users with a variety of applications (e.g. games, navigation and location tracking, 
photograph manipulation, currency conversion) either built-in when purchased, or added later. The use of application 
functionality at a content and information level is beyond the scope of the present document, but all applications should 
provide input, output and control functionality that is usable by all users. 

Applications 

Requirement H.2.a: Users should be able to use the applications installed into the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.b: Users should be able to download and install applications into the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.c: Users should be able to invoke the applications on the mobile device, by the use of AT commands 
from an external device. 

Requirement H.2.d: Users should be able to operate the applications on the mobile device, by the use of AT 
commands from an external device. 

Requirement H.2.e: Users should be able to close down the applications on the mobile device, by the use of AT 
commands from an external device. 

Users should be able to: 

• Access information about available software, to select, purchase and install applications at a functional (not 
content) level. 

• Interact with the applications on the device. This implies just that users can actually operate the applications 
through the user interface input and output interfaces or accessible alternatives. But it does not imply that the 
applications should be usable by all users at the content and information levels. This functionality includes the 
ability to invoke network connectivity and other users (e.g. for multiplayer games) as necessary. 



£75/ 



66 ETSI TS 1 02 51 1 V1 .1 .1 (2007-08) 



H.3 Audio stream 



A person with a speech impairment may need to have a text conversation using a synthetic voice from an assistive 
device, by feeding an audio stream from that assistive device to the mobile device. 

Audio stream 

Requirement H.3: Users should be able to feed an audio stream to and from the assistive device and the mobile device, 
by the use of AT commands from an external device. 



H.4 Calendar 



Users should be able to use the calendar, including reading and writing calendar objects. The calendar AT command 
reads vCalendar objects. 

Calendar 

Requirement H.4.a: Users should be able to use the calendar, by the use of AT commands from an external device. 

Requirement H.4.b: Users should be able to read calendar objects, by the use of AT commands from an external 
device. 

Requirement H.4.c: Users should be able to write calendar objects, by the use of AT commands from an external 
device. 

See clause E. 1 for more details on a suggested AT command syntax. 



H.4.1 Implementation 



Calendar information is transferred using the vCalendar format [6]. Calendar information can also be synchronized 
using OBEX over Bluetooth®, IrDA or cable, which can be initiated with the standardized AT command +CPROT 
(TS 127 007 [2]). 



H.5 Camera 



Users should be able to use the camera functionality of the mobile phone, as it means that they can have multiple 
functions on a single device. This is particularly useful for users with reduced mobility and dexterity who might have a 
device mounted on a wheelchair. 

It should be possible to change the operational characteristics of the camera and configuration aspects of the operational 
characteristics of the camera, including exposure, white balance, focus pre-press and zoom etc and whether the camera 
output is a picture or a video clip. A scenario illustrating the use of camera is described in clause 5.3. 
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Camera 

Requirement H.S.a: Users should be able to use all the camera functionality associated with the phone, by the use of 
AT commands from an external device. 

Requirement H.S.b: Users should be able to select the camera function of the phone, by the use of AT commands from 
an external device. 

Requirement H.S.c: Users should be able to set the camera's operational parameters, by the use of AT commands from 
an external device. 

Requirement H.S.d: Users should be able to operate all the functions of the camera, by the use of AT commands from 
an external device. 

Requirement H.S.e: Users should be able to choose if they want to store photographs and video clips, by the use of AT 
commands from an external device. 

Requirement H.S.f: Users should be able to choose where to store photographs and video clips (e.g. on internal or 
external memory), by the use of AT commands from an external device. 

Requirement H.S.g: Users should be able to send the photographs and video clips immediately using one of the 
messaging services available on the phone, by the use of AT commands from an external device. 

Requirement H.S.h: Users should be able to attribute positional information available in the phone to the photograph, 
by the use of AT commands from an external device. 



H.6 Colour 



Visually impaired people often find it useful to set font and background colours. Many dyslexic people find it easier to 
read when a specific background colour is used. 

Font colour 

Requirement H.6.a: Users should be able to set their preferred font colours, by the use of AT commands from an 
external device. 

Requirement H.6. b: Users should be able to set their preferred background colours, by the use of AT commands from 
an external device. 

See clause E.2 for more details on a suggested AT command syntax. 



H.7 Cursor control 



Mobility-impaired users may need alternative pointing devices to control the on-screen cursor/pointer. The user should 
be able to make a click on a specific coordinate X, Y. The clicks can be various numbers such as single click or double 
click. Clicks can be done with various buttons, so the buttons being used for the click can also be defined. 

The following functions are required: 

• pointingDeviceClick (int X, int Y, int numberOfClicks, int buttonNumber); 

• pointingDeviceMove (int X, int Y); 

• pointingDeviceDrag (int X, int Y, int status) 
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Cursor control 

Requirement H.7: Users should be able to interact with alternative pointing devices, by the use of AT commands from 
an external device. 

See clause E.3 for more details on a suggested AT command syntax. 



H.8 Font size 



Visually impaired users who wish to read information from the screen on the mobile phone should be able to increase 
the font size. 

Font size 

Requirement H.8: Users should be able to set font size, by the use of AT commands from an external device. 

See clause E.4 for more details on a suggested AT command syntax. 



H.9 Location services 



Visually impaired people and those with cognitive impairments such as dementia, may often encounter difficulties to 
locate where they are and where they are going. The use of location services can therefore be very useful for these 
users. This can form the basis of a range of location based assistance and emergency services. 

This functionality provides the ability to gather location information from the network (base station tri angulation) or 
from systems such as GPS. The functionality should include the ability to invoke and configure the function within the 
phone. These functionalities consume a considerable amount of battery power. Power saving is therefore important so 
that the user is be able to set them to time-out if inactive after a certain time, and to switch them off easily. 

Location services 

Requirement H.9.a: Users should be able to invoke the location functionality, by the use of AT commands from an 
external device. 

Requirement H.9.b: Users should be able to configure the operation of the location functionality, by the use of AT 
commands from an external device. 

Requirement H.9.c: User should be able to set the location services to time-out and switch them off, if inactive after a 
certain time, by the use of AT commands from an external device. 

Requirement H.9.d: User should be able to switch off the location services, by the use of AT commands from an 
external device. 



H.10 IVIenu 
H.10.1 Introduction 

The purpose of this functionality is to provide menus in a way that suit users needs. Some users prefer spoken menus 
and others would rather use their preferred font size or font colour. In order to allow assistive devices to present the 
menus in the preferred way, the menus need to be defined in a standardized way. A scenario illustrating the use of 
menus is described in clause 5.2. 
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H.10.2 Requirements 



The assistive device should be able to present the mobile device menus to the user in different modes such as text or 
spoken menus. The user should be able to navigate in the menus in different modes. 

Menu 

Requirement H.10.2.a: Assistive devices should be able to present menus in alternative modes such as text or spoken 
menus, by the use of AT commands. 

Requirement H.10.2.b: Assistive devices should be able to display menus according to users" needs and preferences 
such as font size and colours, by the use of AT commands. 

Requirement H.10.2.c: Users should be able to navigate either on their mobile device or on their assistive device, by 
the use of AT commands. 

See clause E.5 for more details on a suggested AT command syntax. 

H.10.3 Problems with menus 

The use of menus is the main difficulty for visually impaired people [34] when using a mobile phone. One important 
problem is the size of screens on mobile devices as they are often small, and especially visually impaired people might 
prefer to use an external, larger screen (e.g. an assistive device) for displaying the content. As an alternative to larger 
screen, spoken menus would also be useful, in particular for blind people. However, when using spoken menus, the 
privacy issues should be considered. Some users would therefore use a headset in order to prevent other people around 
hearing the content of the menu. 

H.10.4 Advantage compared with screen dump 

Screen dumps that could be sent to the larger size screen could be used for displaying static content, but it would not be 
useful for spoken menus or for personalizing the presentation of content (e.g. having another font colour). It would 
therefore be more useful if menus could be presented in a standardized way and let the assistive device receive the 
logical presentation of the menu so that it could be created and personalized in the assistive device. 

H.10.5 Implementation 

The menus should be internally represented by a list structure and the menu definition as well as the menu operations 
should be defined in a standardized way. 

H.10.6 Navigating on the mobile device 

The user could either navigate in the assistive device or navigate on the mobile device. When navigating on the mobile 
device, there is no need to send navigation information via AT commands. Instead, the assistive device should be 
informed when the menu has been updated. 

H.10.7 Navigating on the assistive device 

If the user is navigating with the assistive device, then there is a need for the assistive device to provide the mobile 
device with the user interactions. 
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H.11 Messaging 

People with hearing impairments and those with speech impairments find messaging services particularly useful. 

There are standardized AT commands for Short Messaging Service (SMS) (TS 127 005 [3]), but none for Multimedia 
Messaging Service (MMS) or e-mail. The messaging functionality includes reading, writing and sending MMS and e- 
mails. 

Messaging 

Requirement H.ll.a: Users should be able to read, write and send MMS, by the use of AT commands from an external 
device. 

Requirement H.ll.b: Users should be able to read, write and send e-mails, by the use of AT commands from an 
external device. 



H.12 Radio 



The radio (e.g. FM) functionality incorporated in mobile phones is becoming increasingly popular and also the users 
with disabilities desire to be able to use this. 

Radio 

Requirement H.12: Users should be able to invoke, configure the operate the radio (e.g. FM) on the mobile device, by 
the use of AT commands from an external device. 



H.13 Screen 



For visually impaired people, it would be very useful if a copy of the screen can be shown in a larger size on the 
assistive device. Also, if would be useful if the contents of the screen as well as the screen dump can be rotated. 

This functionality could be useful in a range of situations such as watching MMS or when navigating in menus (in case 
the assistive device cannot deal with the AT command for menus). This functionality should send still pictures, but 
these could be updated according to the needs depending on the situation. The assistive device may chose to update the 
screen in intervals or according to the user's interactions. 

Screen 

Requirement H.13.a: Users should be able to get a screen dump of their mobile device, for displaying it on their 
assistive device, by the use of AT commands from an external device. 

Requirement H.13.b: Users should be able to rotate the contents of the screen, by the use of AT commands from an 
external device. 

Requirement H.13.c: Users should be able to rotate the contents of the screen dump, by the use of AT commands from 
an external device. 

See clause E.6 for more details on a suggested AT command syntax. 



H.13.1 Implementation alternatives 



It could be implemented by both AT command and OBEX, which could benefit a wider range of assistive devices. AT 
commands is ASCII oriented, whereas OBEX could send the picture in various formats (e.g. jpeg, bmp) which would 
be more efficient than sending it using ASCII. Also, the pictures could be sent via Bluetooth®, for example via the 
Basic Imaging Profile. 
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H.14 Speech-to-text 



The ability of a mobile phone to convert speech-to-text would enable persons who are visually impaired or blind to 
easily enter text. 

Speech-to-text 

Requirement H.14: Users should be able to enable speech-to-text on their mobile device, by the use of AT commands 
from an external device. 

See clause E.7 for more details on a suggested AT command syntax. 



H.15 Text telephony 



Users who are hard of hearing or deaf have traditionally used text telephony for communicating by typing text. Text 
telephony on an assistive device would provide users who are hard of hearing or deaf with a familiar and convenient 
way to communicate, especially when video telephony for some reason is not an option. 

Text telephony 

Requirement H.15: Users should be able to communicate using real time character by character text from an external 
assistive device, by the use of AT commands from an external device (EG 202 116 [1] and COCOM 04-08 [30]). 

See clause E.8 for more details on a suggested AT command syntax. 

H.15.1 Implementation 

The implementation of text telephony can be done in several ways: 

• Through a mix of transfer over the voice channel and transfer digitally as suggested in TS 122 226 [11]. 

• Through the use of IP Multimedia Subsystem (IMS) (TS 126 1 14 [12]) or until IMS is available through the 
current IP and mobile packet switched networks as suggested by the TCAM eWG [31]. 

• etc. 

Regardless of the transport method, the same AT command can be used. 



H . 1 6 Text-To-Speech (TTS) 



Users should be given the option to enable text-to-speech (TTS) on their mobile device. For users with visual 
impairments, text-to-speech is a useful functionality. Settings for speech rate, spelling speed and number read-out 
(options for how numbers larger than four digits will be read) and language option will be available. 

In order to specify the natural language that is used by the text-to-speech (TTS) functionality, the parameter language is 
used. It is defined as specified by the ISO standard for the "representation of names of languages", ISO 639-1 [4] and 
ISO 639-2 [5]. The language codes are based upon the concept of a set of basic languages together with variants based 
upon the country in which they are used (e.g. French used in France is coded as "fr-FR, and when used in Canada is 
coded as "fi--CA"). 

Further enhancements on multicultural and language aspects might be relevant to address in the future. These 
enhancements should be based on the guidelines and suggested future work described in EG 202 421 [8]. 
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Text-to-speech 



Requirement H.16.a: Users should be able to enable text-to-speech on their mobile device, by the use of AT 
commands from an external device. 

Requirement H.16.b: Users should be able to set speech rate, by the use of AT commands from an external device. 

Requirement H.16.c: Users should be able to set spelling speed, by the use of AT commands from an external device. 

Requirement H.16.d: Users should be able to select how numbers larger than four digits will be read, by the use of AT 
commands from an external device. 

Requirement H.16.e: Users should be able to specify the natural language that is used by the text-to-speech 
functionality, by the use of AT commands from an external device. 

See clause E.9 for more details on a suggested AT command syntax. 



H.17 Time-out 



The technical report on "Requirements for assistive technology devices in ICT" (TR 102 068 [7]), has identified the 
need for redefining time-outs, which should allow the user more time to perform various actions. 

Time-out 

Requirement H.17: Users should be able to redefine the time for a range of time-outs, for various actions, by the use of 
AT commands from an external device. 

See clause E.IO for more details on a suggested AT command syntax. 



H.18 Video telephony 



Mobile video telephony in full screen is very useful for users who are hard of hearing or deaf as it enables these users to 
have a conversation in sign language. For example, non-speaking people use video telephony to show pictures and 
symbols to their communicating partners. A scenario illustrating the use of Video telephony is described in clause 5.6. 

Video teleplnony 

Requirement H.18: Users should be able to view a video telephony call in full screen, by the use of AT commands 
from an external device. 



H.19 Voice channel input and output 

Users who are hard of hearing and depend on an assistive device, should be able to connect their hearing aid directly to 
the assistive device and not to the mobile phone. 

Speech impaired users who use an assistive device to amplify their speech, or use their assistive device to speak for 
them should be able to connect their assistive device directly to the mobile phone and use their assistive both for audio 
input and output (see usage scenario 5.3). 

Voice cinannel input and output 

Requirement H.19: Users should be able to connect the voice channel to an assistive device, by the use of AT 
commands from an external device. 
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H.20 Volume 



Media players (e.g. FM radio) on mobile devices are increasingly popular and also people with disabilities desires to 
use that functionality. Users should be able to change the volume of media played on the mobile device. 

Media volume 

Requirement H.20: Users should be able to set the volume of media played on the mobile device, by the use of AT 
commands from an external device. 

See clause E. 1 1 for more details on a suggested AT command syntax. 
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